@luanpdd/kit-mcp 1.9.0 → 1.10.0

package/kit/skills/four-golden-signals/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: four-golden-signals
+description: Use ao instrumentar serviço user-facing — Latency + Traffic + Errors + Saturation, percentis (não mean), histogram exponencial, latência success vs error separadas.
+---
+
+# SRE — Four Golden Signals
+
+## Quando usar
+
+LLM carrega esta skill ao instrumentar Edge Function/serviço/microservice user-facing. Trigger phrases:
+
+- "golden signals", "4 sinais dourados"
+- "latency, traffic, errors, saturation"
+- "instrumentar serviço", "métricas mínimas"
+- "p99 latency", "percentis vs mean"
+- "black-box vs white-box monitoring"
+- "Google SRE cap 6"
+- "Latency success vs error"
+
+## Regras absolutas
+
+- **4 sinais são universais para serviço user-facing** — Latency + Traffic + Errors + Saturation. Se mede esses 4, captura ~95% da saúde operacional. Outros sinais (CPU, memória, disco I/O) são **causas potenciais**, não sintomas — vão em white-box monitoring secundário.
+- **Latency success vs error sempre separadas** — falhas rápidas (HTTP 500 em 5ms) mascaram latência ruim de successes se misturadas. Sempre `histogram(duration_ms, {result: 'success'})` e `histogram(duration_ms, {result: 'error'})` em séries distintas.
+- **NUNCA mean para latency** — long tail invisível: mean=50ms mas p99=5000ms é UX ruim para 1% dos usuários (tipicamente os mais valiosos: enterprise tier). SEMPRE histogram com percentis.
+- **Histogram com bucketing exponencial** — buckets `[1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000]` ms ou base 1.5/2. Captura long tail sem cardinality explosion.
+- **Errors counter por error.type (não message)** — `error.type` enumerado (5-15 valores: `timeout`, `validation`, `auth`, `rate_limit`, `db`, `provider_down`, ...). `error.message` é alta cardinalidade — não usar como dimension.
+- **Saturation é resource-specific** — não existe métrica genérica de saturação. Para HTTP service: connection pool used %. Para DB: tablespace used %. Para queue: queue depth. Para CPU-bound: load average. Identificar O recurso mais escasso ANTES de instrumentar.
+- **Black-box monitora UX, white-box monitora internals** — black-box (synthetic prober HTTP) detecta "site offline" mesmo se métricas internas estão verdes (corner case clássico). White-box (golden signals) explica "porquê" quando black-box dispara.
+- **Reportar p50, p95, p99, p99.9 — não só p99** — p50 (mediana) é UX típica; p95 é primeiro deslize; p99 é cauda; p99.9 é seu 1 em 1000 que é seu cliente enterprise. Cada percentil conta uma história diferente.
+
+## Patterns canônicos
+
+### Pattern: definição canônica dos 4 signals (tabela)
+
+| Signal | Definição | Tipo de instrument | Granularity recomendada |
+|---|---|---|---|
+| **Latency** | Tempo de request bem-sucedido vs falho — SEPARADO | Histogram (ms) com bucketing exponencial | Por endpoint × `result` (success/error) |
+| **Traffic** | Volume de demanda — requests/s, msgs/s, bytes/s | Counter | Por endpoint × method |
+| **Errors** | Taxa de requests que falharam (explícitas: 5xx; implícitas: 200 com payload errado; políticas: > SLO target) | Counter | Por endpoint × `error.type` |
+| **Saturation** | "Quão cheio" o serviço está — % do recurso mais escasso | ObservableGauge (%) | Por resource (connection pool, queue, CPU) |
+
+### Pattern: instrumentação canônica em OTel SDK (TypeScript/Deno)
+
+```ts
+// PT-BR: 4 golden signals em Edge Function — copiar este shape
+import { trace, metrics } from '@opentelemetry/api'
+
+const tracer = trace.getTracer('orders-service')
+const meter = metrics.getMeter('orders-service')
+
+// PT-BR: 1. LATENCY — histogram bucketed exponencial
+const latencyHistogram = meter.createHistogram('http_request_duration_ms', {
+  description: 'Request latency in ms — split by result',
+  unit: 'ms',
+  advice: { explicitBucketBoundaries: [1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000] }
+})
+
+// PT-BR: 2. TRAFFIC — counter de requests recebidos
+const trafficCounter = meter.createCounter('http_requests_total', {
+  description: 'Total HTTP requests received'
+})
+
+// PT-BR: 3. ERRORS — counter por error.type (categoria, não message)
+const errorsCounter = meter.createCounter('http_errors_total', {
+  description: 'Total HTTP errors by error.type'
+})
+
+// PT-BR: 4. SATURATION — gauge do recurso mais escasso
+const saturationGauge = meter.createObservableGauge('db_connection_pool_used_pct', {
+  description: 'DB connection pool utilization %',
+  unit: '%'
+})
+saturationGauge.addCallback((result) => {
+  // PT-BR: callback executado em scrape — lê estado atual do pool
+  result.observe(getConnectionPoolUsedPct(), { resource: 'db_pool', service: 'orders' })
+})
+
+export async function placeOrder(req: Request) {
+  const startMs = performance.now()
+  const dims = { endpoint: '/api/v1/orders', method: 'POST' }
+
+  // PT-BR: 2. Traffic — incrementar antes de processar
+  trafficCounter.add(1, dims)
+
+  return tracer.startActiveSpan('place_order', async (span) => {
+    try {
+      const order = await db.insertOrder(req.body)
+      // PT-BR: 1. Latency success — só após success confirmar
+      const durationMs = performance.now() - startMs
+      latencyHistogram.record(durationMs, { ...dims, result: 'success' })
+      return order
+    } catch (e) {
+      // PT-BR: 1. Latency error — separada da success
+      const durationMs = performance.now() - startMs
+      latencyHistogram.record(durationMs, { ...dims, result: 'error' })
+      // PT-BR: 3. Errors — counter por error.type (enum baixa cardinalidade)
+      errorsCounter.add(1, { ...dims, error_type: classify(e) })
+      throw e
+    } finally {
+      span.end()
+    }
+  })
+}
+
+// PT-BR: classifier — enum estável de 5-15 valores
+function classify(e: unknown): string {
+  if (e instanceof TimeoutError) return 'timeout'
+  if (e instanceof ValidationError) return 'validation'
+  if (e instanceof AuthError) return 'auth'
+  if (e instanceof RateLimitError) return 'rate_limit'
+  if (e instanceof DbError) return 'db'
+  return 'unknown'
+}
+```
+
+### Pattern: queries SQL para 4 signals em 1 dashboard
+
+```sql
+-- PT-BR: dashboard único — 4 golden signals últimos 60 minutos, por minuto
+select
+  date_trunc('minute', timestamp) as minute,
+  -- Traffic
+  count(*) as traffic_rpm,
+  -- Errors (por error.type)
+  count(*) filter (where result_success = false) as errors_total,
+  count(*) filter (where error_type = 'timeout') as errors_timeout,
+  count(*) filter (where error_type = 'rate_limit') as errors_rate_limit,
+  count(*) filter (where error_type = 'db') as errors_db,
+  -- Latency p50/p95/p99 — APENAS success
+  percentile_cont(0.50) within group (order by duration_ms)
+    filter (where result_success = true) as latency_p50_success,
+  percentile_cont(0.95) within group (order by duration_ms)
+    filter (where result_success = true) as latency_p95_success,
+  percentile_cont(0.99) within group (order by duration_ms)
+    filter (where result_success = true) as latency_p99_success,
+  -- Latency p99 — APENAS error (visibilidade de error path lentidão)
+  percentile_cont(0.99) within group (order by duration_ms)
+    filter (where result_success = false) as latency_p99_error,
+  -- Saturation (gauge max no minuto)
+  max(connection_pool_used_pct) as saturation_pool_max
+from observability.events
+where service = 'orders-api' and timestamp > now() - interval '60 minutes'
+group by minute
+order by minute desc;
+```
+
+### Pattern: black-box probe complementar (synthetic check)
+
+```ts
+// PT-BR: black-box monitoring — chamar serviço como cliente externo
+// Roda em CI ou serviço external (uptimerobot, datadog synthetics)
+async function blackBoxProbe(): Promise<{ ok: boolean; durationMs: number }> {
+  const startMs = Date.now()
+  const r = await fetch('https://api.example.com/api/v1/orders/probe', {
+    method: 'POST',
+    body: JSON.stringify({ probe: true, sku: 'TEST-001' }),
+    headers: { 'X-Probe': 'true' }
+  })
+  const durationMs = Date.now() - startMs
+  // PT-BR: validar resposta — não basta status 200
+  const body = await r.json()
+  const ok = r.status === 200 && body.order_id != null && durationMs < 1000
+  return { ok, durationMs }
+}
+
+// PT-BR: rodar a cada 30s; alerta se 3 consecutivos falham (debounce contra flake)
+```
+
+### Pattern: saturation por tipo de serviço
+
+| Tipo de serviço | Recurso mais escasso | Métrica de saturation |
+|---|---|---|
+| HTTP API stateless | Connection pool DB | `db_connection_pool_used_pct` |
+| API com cache | Memory do cache | `cache_memory_used_pct` |
+| Worker async | Queue depth | `queue_depth_messages` |
+| Edge Function | Concurrency limit Deno | `concurrent_executions_pct` |
+| DB | Tablespace ou WAL | `disk_used_pct`, `wal_lag_bytes` |
+| CPU-bound (encoder, ML) | Load average | `cpu_load_avg_5min` |
+| Network egress | Bandwidth | `egress_bytes_per_sec_pct` |
+
+## Anti-patterns
+
+### ANTI: mean latency
+
+```text
+ANTI: alerta/dashboard com avg(duration_ms) — long tail invisível.
+
+PROBLEMA: mean=50ms mas p99=5000ms = UX ruim invisível; cliente enterprise
+          (no p99) sofre sem nunca disparar alerta. Mean é puxado para baixo
+          por mass de requests rápidos; sinaliza "tudo ok" enquanto 1% dos
+          users espera 5s.
+
+CERTO: histogram com percentile_cont(0.99); alertar em p99 > target.
+       Reportar p50/p95/p99/p99.9 para ver formato da distribuição.
+```
+
+### ANTI: latência success+error misturadas
+
+```text
+ANTI: histogram(duration_ms) sem dimension result.
+
+PROBLEMA: falhas rápidas (HTTP 500 em 5ms quando timeout dispara cedo)
+          puxam mean/percentis para baixo; mascaram lentidão real de
+          requests bem-sucedidos. Dashboard mostra "p99=80ms" mas
+          successes reais são 800ms.
+
+CERTO: dimension {result: 'success'} vs {result: 'error'} SEMPRE separadas
+       em séries distintas. SLI/SLO computado APENAS sobre success path.
+```
+
+### ANTI: Errors com error.message como dimension
+
+```text
+ANTI: errorsCounter.add(1, { error_message: e.message })
+
+PROBLEMA: cada mensagem única é uma série temporal; cardinality explosion
+          (1M+ séries em horas se message contém timestamps/IDs/random);
+          time-series DB OOMs ou throttles; queries lentas/impossíveis;
+          custo de armazenamento explode.
+
+CERTO: enum error.type com 5-15 valores fixos (timeout, validation, auth,
+       rate_limit, db, provider_down, unknown); error.message em
+       log/span attribute (não métrica) para debug pontual.
+```
+
+### ANTI: monitoring causes não symptoms
+
+```text
+ANTI: alertar em "CPU > 80% / memory < 10% / threads > N"
+
+PROBLEMA: mistura "what" (sintoma user-facing) com "why" (causa interna);
+          falsos positivos (cron job legítimo dispara CPU);
+          falsos negativos (sistema lento sem CPU alta — saturação em
+          connection pool ou rede); on-call paginado por nada e
+          incidents reais passam silenciosos.
+
+CERTO: alertar em SLO burn rate sobre os 4 signals (event-based,
+       customer-impacting); usar CPU/memory como debug context em
+       white-box monitoring, não como alert source.
+```
+
+### ANTI: saturation genérica
+
+```text
+ANTI: copiar pattern de saturation de outro serviço sem identificar o
+      gargalo real.
+
+PROBLEMA: mede CPU em serviço onde gargalo é connection pool; mede memory
+          em serviço CPU-bound; saturation alerta nunca dispara antes do
+          incident; quando incident acontece, dashboard mostra "saturação
+          OK" e ninguém sabe explicar por quê.
+
+CERTO: identificar EXPLICITAMENTE o recurso mais escasso (DB pool? queue
+       depth? Deno concurrency? tablespace?) ANTES de instrumentar (ver
+       Pattern: saturation por tipo de serviço). Cada serviço tem 1 ou 2
+       gargalos reais — instrumentar esses, não copiar template.
+```
+
+### ANTI: black-box only (sem white-box)
+
+```text
+ANTI: só prober externo (synthetic check), sem instrumentação interna.
+
+PROBLEMA: sabe que "site offline" mas não sabe porquê; debug requer SSH
+          em prod / log dive sem instrumentation; MTTR cresce horas;
+          incidents repetem porque root cause nunca foi capturada.
+
+CERTO: black-box detecta UX impact (cliente real não consegue) + white-box
+       (4 signals) explica root cause. Os dois juntos: black-box dispara,
+       white-box mostra qual signal degradou (latency? errors? saturation?)
+       e em qual endpoint.
+```
+
+## Verificação
+
+Antes de marcar instrumentação como production-ready, validar:
+
+1. **Os 4 signals presentes** — Latency (histogram), Traffic (counter), Errors (counter por error.type), Saturation (gauge resource-specific)
+2. **Latency separada** — `result: 'success'` e `result: 'error'` em séries distintas
+3. **Histogram com bucketing exponencial** — não fixed buckets lineares
+4. **error.type é enum (5-15 valores)** — não `error.message` como dimension
+5. **Saturation tem o recurso certo identificado** — connection pool? queue depth? concurrency? CPU load?
+6. **Black-box probe complementar** — synthetic check do happy path principal a cada 30s
+7. **Dashboard de 4 signals** existe e é o **primeiro** lugar de debug em incident
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — termos canônicos golden signals, black-box, white-box, percentile
+- [`opentelemetry-standard`](../opentelemetry-standard/SKILL.md) (v1.9) — OTel SDK base, exporter, OTLP
+- [`structured-events`](../structured-events/SKILL.md) (v1.9) — wide events que alimentam SLI de Errors
+- [`event-based-slos`](../event-based-slos/SKILL.md) (v1.9) — SLO sobre Errors+Latency forma SLI canônico
+- [`burn-rate-alerting`](../burn-rate-alerting/SKILL.md) (v1.9) — alertar em SLO burn-rate, não em CPU
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) — PRR axis "Instrumentation" exige 4 signals
+
+---
+
+*Material-fonte: Site Reliability Engineering — Beyer, Jones, Petoff, Murphy (Google/O'Reilly, 2016) — Cap 6: "Monitoring Distributed Systems" (Four Golden Signals).*

package/kit/skills/production-readiness-review/SKILL.md

@@ -0,0 +1,305 @@
+---
+name: production-readiness-review
+description: Use antes de aceitar serviço em produção — PRR checklist 6 axes (System/Instrumentation/Emergency/Capacity/Change/Performance), 3 engagement models, handoff dev→SRE.
+---
+
+# SRE — Production Readiness Review (PRR)
+
+## Quando usar
+
+LLM carrega esta skill ao avaliar serviço/feature antes de produção, conduzir handoff dev→SRE, ou definir engagement model. Trigger phrases:
+
+- "PRR", "production readiness review"
+- "production-bound", "ready for prod"
+- "handoff dev to SRE"
+- "engagement model", "early engagement"
+- "SRE platform", "frameworks readiness"
+- "Google SRE cap 32"
+- "system architecture / instrumentation / emergency response / capacity / change / performance"
+
+## Regras absolutas
+
+- **PRR é GATE, não recomendação** — feature/serviço sem PRR aprovado NÃO entra em produção real (apenas dogfooding/staging). Sem gate, "production-ready" vira slogan; com gate, vira invariante.
+- **6 axes obrigatórios** — System Architecture, Instrumentation/Metrics/Monitoring, Emergency Response, Capacity Planning, Change Management, Performance. Pular um axe = aprovação inválida (lacuna oculta vira incident em 6 meses).
+- **3 engagement models — escolher conforme custo do serviço** — Simple PRR (serviços pequenos/internal), Early Engagement (serviços críticos), Frameworks/SRE Platform (serviços built on top of platform). Modelo errado = ou over-investment (Simple para tier-1) ou under-investment (Early para internal tool).
+- **PRR é ANTES, não DEPOIS** — não "deploy primeiro, fazer PRR depois". PRR conclusão é pré-requisito de aceitar tráfego real (≥ 1% de usuários).
+- **PRR é EVIDENCE-BASED, não opinião** — cada item do checklist tem critério verificável (load test report, runbook URL, dashboard link). "Acreditamos que está pronto" ≠ PRR aprovado.
+- **Action items P0 = blocker; P1 = scheduled** — gaps P0 (sem instrumentação básica, sem rollback, sem on-call) bloqueiam aprovação. Gaps P1 (otimização capacidade, runbook adicional) viram tasks com due date — não bloqueiam, mas são tracked.
+- **Reviewer ≠ time dev** — PRR conduzido por SRE ou par externo ao time dev (eyes-on-code novos, viés reduzido). Auto-PRR pelo time dev = oversight.
+- **PRR é vivo, não one-shot** — após mudança maior (rewrite, novo dependency, RPS 10×), re-run PRR. Statement "passou PRR uma vez em 2024" não é evidence em 2026.
+
+## Patterns canônicos
+
+### Pattern: checklist canônico PRR — 6 axes detalhados
+
+````markdown
+```markdown
+# PRR Checklist — <serviço/feature> — <data>
+
+Reviewer: @<sre-or-external>
+Status: Draft | In Review | Approved | Blocked
+
+---
+
+## Axe 1: System Architecture
+
+- [ ] **Redundância**: serviço tolera falha de N instâncias (N=1 mínimo, N=2 ideal). Evidence: deployment manifest (replicas: 2+).
+- [ ] **Single point of failure mapeado**: SPOFs documentados; mitigation plan claro. Evidence: arch diagram + SPOF list.
+- [ ] **Failure modes mapeados**: top 5 modos de falha conhecidos com impact + mitigation. Evidence: failure mode analysis doc.
+- [ ] **Load balancing strategy**: round-robin / least-conn / consistent-hash documentado. Evidence: LB config.
+- [ ] **Graceful degradation**: serviço degrada (não crasha) sob carga ou dependency failure. Evidence: chaos test report ou load test config.
+
+## Axe 2: Instrumentation, Metrics, Monitoring
+
+- [ ] **4 golden signals presentes**: Latency (histogram), Traffic (counter), Errors (counter por error.type), Saturation (gauge). Evidence: dashboard URL + queries.
+- [ ] **SLI/SLO definidos**: ao menos 1 SLO por jornada crítica do user (ver [event-based-slos](../event-based-slos/SKILL.md)). Evidence: SLO.md em `.planning/slos/`.
+- [ ] **Alertas SLO burn-rate**: NÃO threshold em CPU/mem/etc. Evidence: alert rules em código + correlação com SLO definido.
+- [ ] **Logs estruturados**: wide events com campos canônicos (`user.id`, `request.id`, `error.type`, `result.success`, `duration_ms`, `build_id`). Evidence: log query exemplo.
+- [ ] **Traces propagados**: W3C TraceContext header em hops cross-service. Evidence: trace exemplo cross-service.
+
+## Axe 3: Emergency Response
+
+- [ ] **Runbook existe e foi testado**: passos para incident comuns (5+ scenarios). Evidence: URL do runbook + log do último teste.
+- [ ] **On-call rotation definida**: schedule visível, ≥ 2 pessoas, escalation policy. Evidence: PagerDuty/Opsgenie schedule.
+- [ ] **Page routing**: alertas SLO → on-call específico (não generic). Evidence: alert routing rules.
+- [ ] **Escalation policy**: timeline clara (page → 5 min ack → 15 min escalate to L2 → 30 min L3). Evidence: doc.
+- [ ] **Wheel of Misfortune realizado nos últimos 90d**: time praticou response em incident histórico. Evidence: data + participantes.
+
+## Axe 4: Capacity Planning
+
+- [ ] **Load test executado**: pico esperado × 2 testado; report com latency degradation curve. Evidence: load test report.
+- [ ] **RPS limit documentado**: serviço sabe seu max sustainable RPS por instance. Evidence: number + source.
+- [ ] **Auto-scaling testado**: scale-up + scale-down funcionam sem intervenção manual. Evidence: scaling test log.
+- [ ] **Quota/rate-limit por tenant**: tenant abusivo não derruba serviço para outros. Evidence: rate-limit config.
+- [ ] **Headroom ≥ 30%**: capacidade atual / pico esperado ≥ 1.3. Evidence: cálculo + dashboard.
+
+## Axe 5: Change Management
+
+- [ ] **Canary release**: deploys vão para 1% → 10% → 100% com hold em cada estágio. Evidence: CI pipeline config.
+- [ ] **Feature flags**: features novas atrás de flag (deploy ≠ release). Evidence: feature flag service.
+- [ ] **Rollback automatizado**: SLO burn rate > N nos primeiros M min após deploy → rollback automático. Evidence: rollback automation config.
+- [ ] **CI/CD gates obrigatórios**: testes + lint + security scan + load test (em paths críticos). Evidence: CI config.
+- [ ] **Deploy frequency mensurado**: time conhece sua deploy cadence (commits/dia ou /semana). Evidence: metric URL.
+
+## Axe 6: Performance
+
+- [ ] **Latency baseline (p50/p95/p99/p99.9)**: número conhecido para cada percentil principal. Evidence: dashboard query.
+- [ ] **Error budget definido**: SLO target × window definidos; budget calculado. Evidence: SLO.md.
+- [ ] **Saturation tracked**: CPU / memory / connection pool / queue depth — recurso mais escasso identificado. Evidence: gauge query.
+- [ ] **Long tail (p99.9) monitored**: não só p50; alerta se p99.9 > N×p50 (regression detection). Evidence: query.
+- [ ] **Risk continuum justificado**: target SLO escolhido com base em risk × innovation, não default 99.99%. Evidence: justificativa em SLO.md (ver [sre-risk-management](../sre-risk-management/SKILL.md)).
+
+---
+
+## Action Items
+
+| # | Axe | Item | Severity | Owner | Due |
+|---|-----|------|----------|-------|-----|
+| 1 | 2 | Adicionar saturation gauge em /api/v1/orders | P0 | @bob | 2026-05-15 |
+| 2 | 4 | Documentar RPS limit em runbook | P1 | @alice | 2026-05-22 |
+
+## Decisão
+
+- [x] **Approved** — service production-ready
+- [ ] **Approved with conditions** — P1s tracked, P0s blockers em release próximo
+- [ ] **Blocked** — P0 gaps; service NÃO aceita tráfego real até resolução
+
+## Reviewer signature
+
+Reviewer: @<sre>
+Date: YYYY-MM-DD
+```
+````
+
+### Pattern: 3 engagement models — quando usar cada
+
+| Modelo | Quando usar | SRE involvement | Custo SRE |
+|---|---|---|---|
+| **Simple PRR** | Serviços pequenos, internal tools, dogfood-only | Reviewer 1 sessão; checklist preenchido por dev | Baixo (4-8h) |
+| **Early Engagement** | Serviços críticos (tier-1), customer-facing, expected RPS > 1k/s | SRE participa do design; junior review em milestones; full PRR pré-launch | Médio (semanas) |
+| **Frameworks / SRE Platform** | Serviços built on top of plataforma SRE-blessed (lib + templates + gates já PRR-ready) | SRE manteve plataforma; dev usa scaffolds; PRR é confirmação que dev seguiu plataforma | Baixo recorrente, alto setup inicial |
+
+Modelo escolhido pelo **custo de outage** do serviço:
+
+- Outage < $1k/min → Simple PRR (1 sessão, checklist)
+- Outage $1k-100k/min → Early Engagement (SRE no design)
+- Outage > $100k/min OR > 10 microserviços similares → Platform (libs/scaffolds eliminam toil de PRR)
+
+### Pattern: handoff dev → SRE — sequência canônica
+
+```text
+1. Dev declara intenção: "Esse serviço vai produção em 2026-MM-DD."
+2. Reviewer SRE aceita engagement model (Simple/Early/Platform).
+3. Dev preenche PRR checklist (6 axes) com evidence em cada item.
+4. Reviewer abre PRR-REPORT.md em .planning/prr/<service>.md, score cada axe (Pass/Fail/N-A).
+5. Reviewer + dev discutem gaps:
+   - P0 (blocker): dev resolve antes de production ship
+   - P1 (scheduled): owner + due date; tracked em roadmap
+   - P2 (optional): documentado mas não obrigatório
+6. Após P0s resolvidos, reviewer marca Approved e assina.
+7. Dev ship (canary 1% → 100%).
+8. Pós-launch: SRE review SLO compliance em 7d, 30d, 90d.
+9. Re-PRR triggered em mudanças maiores (rewrite, RPS 10×, novo dependency tier-1).
+```
+
+### Pattern: SRE Platform como amplificador
+
+```text
+Plataforma SRE consiste em:
+
+1. Library/SDK que codifica boas práticas (otel-by-default, structured-logging-by-default,
+   4-golden-signals-by-default, rate-limit-by-default, circuit-breaker-by-default)
+2. Scaffolds/templates de novo serviço (kit-mcp 's `/sre`, e.g., `/sre new-service <name>`)
+3. CI gates que verificam adequação à plataforma (gates de Phase 41:
+   golden-signals-coverage, postmortem-template-required, prr-checklist-coverage)
+4. Runbook templates por categoria de serviço (HTTP API, async worker, batch job)
+
+Resultado: novo serviço nasce com 80% do PRR já passado por design.
+PRR vira confirmação ("você usou a plataforma?"), não auditoria de zero.
+
+Trade-off: setup inicial alto (semanas-meses para escrever plataforma).
+Recomendado para org com 10+ microserviços similares.
+```
+
+### Pattern: PRR-REPORT.md template canônico
+
+````markdown
+```markdown
+# PRR-REPORT — <serviço/feature> — <data>
+
+**Reviewer:** @<sre-or-external>
+**Engagement model:** Simple PRR | Early Engagement | Frameworks/Platform
+**Status:** Approved | Approved with conditions | Blocked
+
+## Sumário executivo
+
+Resultado por axe (1-2 linhas cada):
+
+| Axe | Score | Status |
+|-----|-------|--------|
+| 1. System Architecture | 5/5 | Pass |
+| 2. Instrumentation, Metrics, Monitoring | 4/5 | Pass with gaps |
+| 3. Emergency Response | 3/5 | Fail (P0) |
+| 4. Capacity Planning | 4/5 | Pass with gaps |
+| 5. Change Management | 5/5 | Pass |
+| 6. Performance | 4/5 | Pass with gaps |
+
+## Detalhamento por axe
+
+[seção por axe com itens checked + evidence + gaps]
+
+## Action Items
+
+[tabela com P0/P1/P2 + owner + due]
+
+## Aprovação
+
+[Approved / Approved with conditions / Blocked]
+[Assinatura + data]
+```
+````
+
+## Anti-patterns
+
+### ANTI: PRR depois do launch
+
+```text
+ANTI: fazer PRR após serviço já em produção.
+
+PROBLEMA: gaps P0 já causaram incidents (sem instrumentação significa SEV1 cego);
+          valor de gate perdido; PRR vira post-mortem disfarçado.
+
+CERTO: PRR ANTES de aceitar tráfego real (≥ 1%); blocker se P0 pendente.
+       PRR conclusão é pré-requisito de aceitar tráfego, não follow-up.
+```
+
+### ANTI: auto-PRR pelo time dev
+
+```text
+ANTI: time dev preenche checklist + auto-aprova.
+
+PROBLEMA: confirmation bias (dev acredita que serviço é maduro); itens vagos
+          passam ("Sim, temos monitoring"); gaps invisíveis até incident.
+
+CERTO: reviewer EXTERNO ao time (SRE ou outro time dev sênior); evidence-based
+       em cada item; dev preenche, externo verifica.
+```
+
+### ANTI: pular axes "menos relevantes"
+
+```text
+ANTI: "Esse serviço é simples, não precisa de capacity planning."
+
+PROBLEMA: axe pulado vira lacuna; "simples" é subjetivo; decisão baseada em
+          assumption sem evidence.
+
+CERTO: TODOS os 6 axes preenchidos. Item N/A é resposta válida (com justificativa)
+       — pular silenciosamente NÃO é. Para serviços pequenos, model "Simple PRR"
+       cobre os 6 em 4-8h.
+```
+
+### ANTI: PRR como rubber stamp
+
+```text
+ANTI: reviewer aprova sem ler evidence; meeting 15 min; checklist marcado "looks good".
+
+PROBLEMA: first-incident (em 3-6 meses) revela 5+ gaps; reviewer responsabilidade
+          compartilhada por incident.
+
+CERTO: reviewer aplica time-budget (4-8h Simple, dias Early); evidence verificada
+       em cada item; não-OK = blocker, não "todos têm gaps".
+```
+
+### ANTI: engagement model errado para custo
+
+```text
+ANTI: Simple PRR para tier-1 (outage > $100k/min) OU Early Engagement para internal
+       tool com 5 usuários.
+
+PROBLEMA: Simple para tier-1 — SRE não engajou no design; problemas estruturais
+          inviáveis de fix pós-launch; tier-1 com instabilidade. Early para
+          internal tool — over-investment SRE; deslocamento de trabalho importante.
+
+CERTO: escolher model conforme custo de outage (regra do glossário: < $1k/min =
+       Simple, > $100k/min = Platform).
+```
+
+### ANTI: PRR one-shot
+
+```text
+ANTI: passou PRR em 2024, foi para prod, nunca re-PRR'd.
+
+PROBLEMA: 2 anos depois — dependency new, RPS 10×, código rewrote, time rotated;
+          PRR original irrelevante.
+
+CERTO: re-PRR triggered em (a) rewrite > 50%, (b) RPS escala > 10×, (c) novo
+       dependency tier-1, (d) time-of-record rotation > 50%, (e) anualmente como
+       hygiene.
+```
+
+## Verificação
+
+Antes de marcar PRR como `Approved`:
+
+1. **6 axes preenchidos** — System Architecture, Instrumentation/Metrics/Monitoring, Emergency Response, Capacity Planning, Change Management, Performance
+2. **Cada item tem evidence** — não checkbox vago; evidence concreta (URL/query/doc) em cada
+3. **Engagement model escolhido apropriadamente** — Simple PRR/Early Engagement/Frameworks-Platform conforme custo de outage
+4. **Reviewer ≠ time dev** — reviewer externo ou SRE
+5. **P0s todos resolvidos** — gaps P0 são blockers; nenhum aberto pré-launch
+6. **P1s tracked com owner + due** — escalonados em roadmap próximo
+7. **PRR-REPORT.md em `.planning/prr/<service>.md`** — formato canônico
+8. **Re-PRR trigger documentado** — quando re-PRR é triggered (rewrite, RPS 10×, etc.)
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — termos canônicos PRR, 6 axes, 3 engagement models
+- [`four-golden-signals`](../four-golden-signals/SKILL.md) — Axe 2 (Instrumentation) exige os 4 signals
+- [`event-based-slos`](../event-based-slos/SKILL.md) (v1.9) — Axe 6 (Performance) exige SLO definido
+- [`burn-rate-alerting`](../burn-rate-alerting/SKILL.md) (v1.9) — Axe 2 (Instrumentation) exige SLO burn-rate alerts
+- [`sre-risk-management`](../sre-risk-management/SKILL.md) — Axe 6 (Performance) requer risk continuum justificativa
+- [`blameless-postmortems`](../blameless-postmortems/SKILL.md) — Axe 3 (Emergency Response) exige postmortem culture
+- [`eliminating-toil`](../eliminating-toil/SKILL.md) — Axe 5 (Change Management) verifica deploy não é toil
+
+---
+
+*Material-fonte: Site Reliability Engineering — Beyer, Jones, Petoff, Murphy (Google/O'Reilly, 2016) — Cap 32: "The Evolving SRE Engagement Model".*