@luanpdd/kit-mcp 1.8.1 → 1.10.0

package/kit/skills/opentelemetry-standard/SKILL.md

@@ -0,0 +1,351 @@
+---
+name: opentelemetry-standard
+description: Use ao adotar OTel — SDK + API + Tracer + Meter + Exporter + OTLP + Collector. Auto-instrumentation primeiro, custom attrs depois. Vendor-neutral por design.
+---
+
+# Observabilidade — OpenTelemetry (OTel)
+
+## Quando usar
+
+LLM carrega esta skill ao instrumentar código com OpenTelemetry. Trigger phrases:
+
+- "OpenTelemetry", "OTel"
+- "instrumentação vendor-neutral"
+- "OTel SDK Tracer Meter Exporter Collector"
+- "OTLP exporter"
+- "auto-instrumentation"
+- "OTel para Edge Function Deno", "OTel Node.js"
+
+## Regras absolutas
+
+- **Use OTel sempre** — vendor-neutral por design. Não adote APM proprietário no código aplicacional. Trocar backend = trocar exporter, não código.
+- **API ≠ SDK** — `@opentelemetry/api` é o que devs importam (especificação). `@opentelemetry/sdk-*` é a implementação. Use API em libs, SDK no entry-point do app.
+- **Auto-instrumentation primeiro** — instale `@opentelemetry/auto-instrumentations-node` (ou Deno equivalente) e tenha tracing de HTTP/gRPC/DB grátis em minutos. Depois adicione custom attrs.
+- **Configure SDK NO ENTRY-POINT** — antes de qualquer outro require/import. Caso contrário, instrumentation patches não pegam.
+- **Use OTLP como wire format** — porta 4318 (HTTP) ou 4317 (gRPC). É o padrão; todos os backends modernos aceitam.
+- **Collector como sidecar** — em produção, app envia OTLP para Collector local (porta 4318). Collector roteia para destino final. Permite trocar destino sem redeploy.
+- **Tracer name = component name** — `trace.getTracer('orders-service')`, não `trace.getTracer('default')`.
+- **Resource attributes obrigatórios** — `service.name`, `service.version`, `deployment.environment`. Setados 1× no SDK setup.
+- **Não polua o tracer global** — em libs, exponha como parâmetro ou use named tracer. Não dependa de tracer global.
+
+## Componentes OTel
+
+| Componente | Responsabilidade | Exemplo de uso |
+|---|---|---|
+| **API** | Especificação (interface) | `import { trace } from '@opentelemetry/api'` |
+| **SDK** | Implementação concreta | `import { NodeSDK } from '@opentelemetry/sdk-node'` |
+| **Tracer** | Cria e gerencia spans | `trace.getTracer('my-service')` |
+| **Meter** | Cria e gerencia métricas | `metrics.getMeter('my-service')` |
+| **Context propagation** | Serializa/extrai contexto entre services | `propagation.inject()`, `propagation.extract()` |
+| **Exporter** | Envia dados para backend | `OTLPTraceExporter`, `JaegerExporter`, etc. |
+| **Collector** | Proxy/sidecar standalone | Binário `otelcol` |
+| **OTLP** | Wire protocol default | HTTP 4318, gRPC 4317, Protobuf |
+
+## Patterns canônicos
+
+### Pattern: SDK setup Node.js (entry-point)
+
+```ts
+// PT-BR: arquivo `instrumentation.ts` — IMPORTAR ANTES de qualquer outra coisa
+// Em package.json: "node --import ./instrumentation.ts ./src/index.ts"
+import { NodeSDK } from '@opentelemetry/sdk-node'
+import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'
+import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http'
+import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics'
+import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node'
+import { resourceFromAttributes } from '@opentelemetry/resources'
+import {
+  ATTR_SERVICE_NAME,
+  ATTR_SERVICE_VERSION,
+} from '@opentelemetry/semantic-conventions'
+
+const sdk = new NodeSDK({
+  resource: resourceFromAttributes({
+    [ATTR_SERVICE_NAME]: 'orders-service',
+    [ATTR_SERVICE_VERSION]: process.env.BUILD_ID ?? 'dev',
+    'deployment.environment': process.env.NODE_ENV ?? 'development',
+  }),
+  traceExporter: new OTLPTraceExporter({
+    url: 'http://localhost:4318/v1/traces',  // PT-BR: Collector local
+  }),
+  metricReader: new PeriodicExportingMetricReader({
+    exporter: new OTLPMetricExporter({
+      url: 'http://localhost:4318/v1/metrics',
+    }),
+    exportIntervalMillis: 10_000,
+  }),
+  instrumentations: [getNodeAutoInstrumentations()],
+})
+
+sdk.start()
+
+// PT-BR: graceful shutdown — flush pending traces
+process.on('SIGTERM', () => {
+  sdk.shutdown().finally(() => process.exit(0))
+})
+```
+
+### Pattern: SDK setup Deno (Edge Function)
+
+```ts
+// PT-BR: setup OTel em Edge Function — pode ser arquivo `_otel.ts` importado primeiro
+import { NodeSDK } from 'npm:@opentelemetry/sdk-node@0.55.0'
+import { OTLPTraceExporter } from 'npm:@opentelemetry/exporter-trace-otlp-http@0.55.0'
+import { resourceFromAttributes } from 'npm:@opentelemetry/resources@1.27.0'
+
+const sdk = new NodeSDK({
+  resource: resourceFromAttributes({
+    'service.name': 'edge-process-emails',
+    'service.version': Deno.env.get('SUPABASE_GIT_SHA') ?? 'local',
+    'deployment.environment': Deno.env.get('SUPABASE_ENV') ?? 'production',
+  }),
+  traceExporter: new OTLPTraceExporter({
+    // PT-BR: em Supabase, OTLP collector pode rodar como sidecar ou
+    //         enviar direto para destino externo (Honeycomb, etc.)
+    url: Deno.env.get('OTLP_ENDPOINT') ?? 'http://localhost:4318/v1/traces',
+    headers: {
+      // PT-BR: backends comerciais usam header de auth aqui
+      authorization: `Bearer ${Deno.env.get('OTLP_TOKEN') ?? ''}`,
+    },
+  }),
+})
+
+sdk.start()
+```
+
+### Pattern: usar Tracer em código
+
+```ts
+import { trace, SpanKind, SpanStatusCode } from '@opentelemetry/api'
+
+// PT-BR: 1× por arquivo/módulo — nome do componente
+const tracer = trace.getTracer('orders-service')
+
+export async function placeOrder(req: Request) {
+  return tracer.startActiveSpan(
+    'place_order',
+    { kind: SpanKind.SERVER },
+    async (span) => {
+      span.setAttribute('user.id', req.user.id)
+      try {
+        const order = await db.insertOrder(req.body)
+        span.setAttribute('order.id', order.id)
+        span.setStatus({ code: SpanStatusCode.OK })
+        return order
+      } catch (e) {
+        span.recordException(e as Error)
+        span.setStatus({ code: SpanStatusCode.ERROR, message: e.message })
+        throw e
+      } finally {
+        span.end()
+      }
+    }
+  )
+}
+```
+
+### Pattern: usar Meter (métricas)
+
+```ts
+import { metrics } from '@opentelemetry/api'
+
+const meter = metrics.getMeter('orders-service')
+
+// PT-BR: counter para eventos contáveis
+const ordersCreated = meter.createCounter('orders.created.total', {
+  description: 'Total orders created',
+})
+
+// PT-BR: histogram para distribuições (latency)
+const orderDuration = meter.createHistogram('orders.duration_ms', {
+  description: 'Order placement duration in ms',
+  unit: 'ms',
+})
+
+export async function placeOrder(req: Request) {
+  const start = Date.now()
+  try {
+    const order = await db.insertOrder(req.body)
+    ordersCreated.add(1, {
+      'tenant_id': req.user.tenant,
+      'customer.tier': req.user.tier,
+      'result.success': true,
+    })
+    return order
+  } finally {
+    orderDuration.record(Date.now() - start, {
+      'tenant_id': req.user.tenant,
+    })
+  }
+}
+```
+
+### Pattern: OTel Collector config (otelcol-config.yaml)
+
+```yaml
+# PT-BR: collector como sidecar — recebe OTLP, processa, exporta para múltiplos destinos
+receivers:
+  otlp:
+    protocols:
+      http:
+        endpoint: 0.0.0.0:4318
+      grpc:
+        endpoint: 0.0.0.0:4317
+
+processors:
+  batch:
+    timeout: 10s
+    send_batch_size: 1024
+  # PT-BR: tail-based sampling — 100% errors, 1% successes
+  tail_sampling:
+    decision_wait: 10s
+    policies:
+      - name: errors-policy
+        type: status_code
+        status_code: { status_codes: [ERROR] }
+      - name: probabilistic-policy
+        type: probabilistic
+        probabilistic: { sampling_percentage: 1 }
+
+exporters:
+  # PT-BR: para Honeycomb (exemplo)
+  otlphttp/honeycomb:
+    endpoint: https://api.honeycomb.io
+    headers:
+      x-honeycomb-team: ${env:HONEYCOMB_API_KEY}
+  # PT-BR: para arquivo local — debug
+  file:
+    path: /var/log/otel-traces.json
+  # PT-BR: para Logflare (Supabase)
+  otlphttp/logflare:
+    endpoint: https://api.logflare.app/otel
+    headers:
+      x-api-key: ${env:LOGFLARE_API_KEY}
+
+service:
+  pipelines:
+    traces:
+      receivers: [otlp]
+      processors: [tail_sampling, batch]
+      exporters: [otlphttp/honeycomb, file]
+```
+
+### Pattern: rodar Collector via Docker (dev)
+
+```bash
+# PT-BR: Collector local com config customizado
+docker run -p 4317:4317 -p 4318:4318 \
+  -v "$(pwd)/otelcol-config.yaml":/etc/otelcol/config.yaml \
+  -e HONEYCOMB_API_KEY="$HONEYCOMB_API_KEY" \
+  otel/opentelemetry-collector:latest \
+  --config=/etc/otelcol/config.yaml
+```
+
+### Pattern: tracegen — testar pipeline
+
+```bash
+# PT-BR: gera 100 traces sintéticos, 10/segundo, valida que pipeline está vivo
+go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest
+telemetrygen traces --otlp-insecure --otlp-endpoint=localhost:4317 --traces 100 --rate 10
+```
+
+## Anti-patterns
+
+### ANTI: configurar SDK depois de imports
+
+```ts
+// PT-BR: BAD — instrumentation patches não pegam código já carregado
+import express from 'express'   // express já carregado, sem patches OTel
+import { NodeSDK } from '@opentelemetry/sdk-node'
+new NodeSDK({...}).start()       // tarde demais
+
+// PT-BR: GOOD — SDK no entry-point com `--import`
+// node --import ./instrumentation.ts ./src/index.ts
+// (instrumentation.ts inicializa SDK antes de qualquer outro código)
+```
+
+### ANTI: usar SDK em libs
+
+```ts
+// PT-BR: BAD — lib importa SDK, força app a usar mesma versão
+import { NodeSDK } from '@opentelemetry/sdk-node'  // em uma lib
+
+// PT-BR: GOOD — lib só importa API, app traz SDK
+import { trace } from '@opentelemetry/api'  // lib usa só API
+```
+
+### ANTI: tracer global anônimo
+
+```ts
+// PT-BR: BAD — sem nome de componente, dificulta filtrar por service em queries
+const tracer = trace.getTracer('default')
+
+// PT-BR: GOOD — nome do component
+const tracer = trace.getTracer('orders-service')
+```
+
+### ANTI: backend proprietary direto
+
+```ts
+// PT-BR: BAD — code aplicacional acoplado a vendor
+import { Datadog } from 'dd-trace'  // 6 meses depois quer trocar = refactor massivo
+
+// PT-BR: GOOD — OTel + exporter trocável via config
+import { trace } from '@opentelemetry/api'
+// trocar backend = trocar exporter no SDK setup, não código
+```
+
+### ANTI: instrumentar sem resource attributes
+
+```ts
+// PT-BR: BAD — sem service.name, query SELECT WHERE service = ? não funciona
+new NodeSDK({ traceExporter: ... })
+
+// PT-BR: GOOD — resource sempre presente
+new NodeSDK({
+  resource: resourceFromAttributes({
+    'service.name': 'orders-service',
+    'service.version': BUILD_ID,
+    'deployment.environment': ENV,
+  }),
+  traceExporter: ...
+})
+```
+
+### ANTI: enviar OTLP direto para múltiplos backends
+
+```ts
+// PT-BR: BAD — app conhece todos os destinos (Honeycomb, Datadog, Logflare)
+//                 redeploy obrigatório para mudar destino
+new NodeSDK({
+  traceExporter: new OTLPTraceExporter({ url: 'https://honeycomb.io...' }),
+})
+
+// PT-BR: GOOD — app envia para Collector local; Collector roteia
+new NodeSDK({
+  traceExporter: new OTLPTraceExporter({ url: 'http://localhost:4318/v1/traces' }),
+})
+// PT-BR: Collector decide para onde mandar (Honeycomb + Logflare + arquivo) via config
+```
+
+## Verificação
+
+1. **SDK iniciou** — log no setup: "OTel SDK started for service=orders-service version=...". Sem isso, traces não saem.
+2. **Auto-instrumentation ativa** — fazer 1 request HTTP via fetch ou axios → span aparece em `select * from spans` sem código manual.
+3. **OTLP sendo enviado** — `tcpdump port 4318` durante request real → tráfego POST visível.
+4. **Resource attributes corretos** — `select distinct service_name, service_version FROM spans` → resultado esperado.
+5. **Tracer custom funciona** — adicionar `tracer.startSpan('custom')` → span aparece queryable.
+6. **Collector roteando** — fazer request → trace aparece em DESTINO 1 (Honeycomb) e DESTINO 2 (arquivo local) simultaneamente.
+7. **Graceful shutdown** — `kill -TERM` no app → SDK flush pendente; sem traces perdidos no shutdown.
+
+---
+
+## Ver também
+
+- `kit/skills/_shared-observability/glossary.md` — termos OTel canônicos
+- `kit/skills/structured-events/SKILL.md` — campos canônicos por span
+- `kit/skills/distributed-tracing/SKILL.md` — context propagation cross-service
+- `kit/skills/telemetry-pipelines/SKILL.md` *(Phase 34)* — Collector config avançada
+- `kit/skills/telemetry-sampling/SKILL.md` *(Phase 34)* — sampling no Collector
+
+*Material-fonte: Observability Engineering (O'Reilly, 2022) — Cap 7: "Instrumentation with OpenTelemetry".*

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".*