@luanpdd/kit-mcp 1.9.0 → 1.11.0

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

package/kit/skills/release-engineering/SKILL.md

@@ -0,0 +1,367 @@
+---
+name: release-engineering
+description: Use ao desenhar/auditar pipeline de release — deployment philosophy, self-service, policy enforcement, canary, rollback, branching strategy, release invariants. Cap 8 livro Google SRE.
+---
+
+# SRE — Release Engineering
+
+## Quando usar
+
+LLM carrega esta skill ao desenhar pipeline de deploy ou ao investigar release fragility. Trigger phrases:
+
+- "release pipeline", "deploy pipeline"
+- "canary release", "rollback"
+- "branching strategy", "trunk-based development"
+- "deployment philosophy"
+- "policy enforcement"
+- "release engineering"
+- "cap 8 Google SRE"
+
+## Regras absolutas
+
+- **Release engineering é DISCIPLINA SEPARADA.** Cuida de "código no merge → bits em prod". Não é dev (que produz código), não é SRE clássico (que opera prod). É a ponte.
+- **4 invariantes canônicos (cap 8):**
+  1. **Self-service:** engineers deployam sozinhos via CLI/UI (sem aprovação manual SRE)
+  2. **High velocity:** deploy ≥ 1×/dia (ideal: cada merge)
+  3. **Hermetic builds:** input idêntico → output idêntico
+  4. **Policy enforcement:** policies em ferramenta, não em humano
+- **Trunk-based development > GitFlow.** Main sempre deployable. Feature flags para work in progress. Branches longos = harder rollback + merge hell.
+- **Canary release OBRIGATÓRIO em prod.** 1% → 10% → 50% → 100% com SLO check em cada estágio. Bug detectado em 1% afeta < 1% dos users.
+- **Rollback < 5 min, exercitado.** Schema migrations sempre forward-compatible OR reversible. Artefato N-1 preservado.
+- **Config separada de código (12-factor).** Config versionada, audit-able, GitOps. ConfigMaps, env vars, feature flags. NUNCA hardcoded em image.
+- **Continuous build + test + deploy.** Cada commit dispara pipeline. Deploy contínuo (push tag → prod) preferred a continuous delivery (deploy disponível mas manual).
+- **Release pipeline tem audit trail.** Quem deployou, quando, qual commit, qual artefato. Auto-gerado via CI logs + tags + GitHub Releases.
+
+## Patterns canônicos
+
+### Pattern 1: 4 invariantes canônicos
+
+```text
+1. SELF-SERVICE
+   ============
+   ANTI: engineer abre ticket → SRE aprova → SRE deploya
+   CERTO: engineer roda `gh workflow run deploy.yml` → workflow valida policies →
+          deploy automático
+   Implementação: GitHub Actions / GitLab CI / Argo CD com approval rules.
+
+2. HIGH VELOCITY
+   ==============
+   Métrica DORA: deployment frequency
+     Elite: multiple per day
+     High: weekly
+     Medium: monthly
+     Low: < monthly (problem)
+   Implementação: trunk-based + feature flags + small commits + CI fast.
+
+3. HERMETIC BUILDS (skill separada)
+   =================================
+   Mesmo commit + lockfile → mesmo artefato. SLSA Level 3+.
+
+4. POLICY ENFORCEMENT
+   ===================
+   Policies em ferramenta, não em humanos:
+     - branch protection (no direct push to main)
+     - required reviewers (≥ 1 ou ≥ 2 dependendo de criticality)
+     - required CI checks (build + test + lint + security scan)
+     - signed commits (GPG keys)
+     - production deploy só de tagged releases
+   Implementação: GitHub branch protection + CODEOWNERS + custom Actions.
+```
+
+### Pattern 2: Trunk-based development workflow
+
+```text
+Trunk-based (Google + Facebook + Netflix):
+
+main (deployable)
+  ├── feat/A (24-48h)  → merge → DELETE branch
+  ├── feat/B (24-48h)  → merge → DELETE branch
+  └── ...
+
+Pré-requisitos:
+  ✓ Feature flags para work in progress (incomplete features hidden)
+  ✓ CI rápido (≤ 10min) — feedback fast
+  ✓ Tests forte (> 80% coverage; flaky < 1%)
+  ✓ Pair programming OU async PR review
+
+vs GitFlow:
+  - develop branch (3-7 dias)
+  - release branch (1-3 dias)
+  - hotfix branch (em incident)
+  - main reflete prod
+  PROBLEMS: merge hell, slow integration, branch divergence
+
+Quando preferir GitFlow (raramente):
+  - Long release cycles obrigatórios (regulamentação healthcare/finance)
+  - Customers need múltiplas versões em paralelo (LTS branches)
+```
+
+### Pattern 3: Canary release pipeline canônico
+
+```yaml
+# GitHub Actions deploy.yml — canary release
+name: Deploy
+
+on:
+  push:
+    tags: ['v*']
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm build
+      - uses: actions/upload-artifact@v4
+        with: { name: dist, path: dist/ }
+
+  canary-1pct:
+    needs: build
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/download-artifact@v4
+      - run: ./scripts/deploy-canary.sh --percent 1
+      - run: sleep 600  # observe por 10 min
+      - run: ./scripts/check-slo.sh --window 10m --threshold 99.9
+      # Se SLO falhar → workflow falha → human intervention
+
+  canary-10pct:
+    needs: canary-1pct
+    runs-on: ubuntu-latest
+    steps:
+      - run: ./scripts/deploy-canary.sh --percent 10
+      - run: sleep 600
+      - run: ./scripts/check-slo.sh --window 10m --threshold 99.9
+
+  canary-50pct:
+    needs: canary-10pct
+    runs-on: ubuntu-latest
+    steps:
+      - run: ./scripts/deploy-canary.sh --percent 50
+      - run: sleep 600
+      - run: ./scripts/check-slo.sh --window 10m --threshold 99.9
+
+  full-rollout:
+    needs: canary-50pct
+    runs-on: ubuntu-latest
+    steps:
+      - run: ./scripts/deploy-full.sh
+      - run: sleep 1800  # observe por 30 min
+      - run: ./scripts/check-slo.sh --window 30m --threshold 99.9
+```
+
+**SLO check em cada stage:** burn rate ≤ baseline × 2 = OK; > 2 = abort + rollback.
+
+### Pattern 4: Rollback canônico
+
+```bash
+# PT-BR: rollback workflow
+# Pré-requisito: artefato N-1 preservado (image registry, S3, etc.)
+
+# 1. Detectar problema (manual OR auto via SLO burn alert v1.9)
+# 2. Identificar versão atual + anterior
+CURRENT=$(kubectl get deployment app -o jsonpath='{.spec.template.spec.containers[0].image}')
+PREVIOUS=$(./scripts/get-previous-deploy.sh app)
+
+# 3. Rollback (1 comando)
+kubectl set image deployment/app app="$PREVIOUS"
+
+# 4. Verificar — SLO burn estabilizou?
+./scripts/check-slo.sh --window 5m --threshold 99.9
+
+# 5. Audit trail — registrar em incident
+echo "Rollback de $CURRENT para $PREVIOUS at $(date)" >> .planning/incidents/<id>.md
+
+# Target: rollback < 5 min, da decisão à observabilidade estabilizada
+```
+
+**Schema migration considerations:**
+- ADD column nullable + default → forward-compatible (rollback OK)
+- DROP column → NOT-rollback-able (forward-fix required)
+- ALTER column NOT NULL com default → reversible se default preservado
+- Sempre escrever migration UP + DOWN (mesmo que UP forward-only)
+
+### Pattern 5: Configuration management (12-factor)
+
+```text
+12-factor app princípios canônicos:
+
+I.    Codebase — single repo per app
+II.   Dependencies — explicit (lockfile)
+III.  Config — env vars OR ConfigMap (NÃO hardcoded)
+IV.   Backing services — attached resources via env
+V.    Build/Release/Run — strict separation
+VI.   Processes — stateless
+VII.  Port binding — self-contained
+VIII. Concurrency — scale via process model
+IX.   Disposability — fast startup + graceful shutdown
+X.    Dev/prod parity — same code, same DB type, same OS
+XI.   Logs — stdout/stderr (não files)
+XII.  Admin processes — one-off scripts em mesmo env
+
+Implementação Supabase:
+  - Edge Function env vars: Deno.env.get('SUPABASE_URL') etc.
+  - Secrets via supabase secrets set
+  - Config NÃO commitado (tem .env.example, sem .env)
+  - Migrations via supabase/migrations (versionado)
+  - Feature flags via env OR Supabase row em config table
+```
+
+### Pattern 6: Branch protection + CODEOWNERS
+
+```yaml
+# .github/CODEOWNERS
+# PT-BR: define quem revisa cada path
+
+# Default — qualquer maintainer
+*                                @luanpdd
+
+# Critical paths — exigir aprovação SRE
+/supabase/migrations/             @luanpdd @sre-team
+/src/auth/                        @luanpdd @security-team
+/.github/workflows/               @luanpdd @sre-team
+/gates/                           @luanpdd
+
+# UI changes — designer review
+/src/components/                  @luanpdd @design-team
+```
+
+```text
+GitHub branch protection rules para `main`:
+  ✓ Require pull request before merging
+  ✓ Require approvals: 1 (or 2 for critical)
+  ✓ Dismiss stale reviews on push
+  ✓ Require review from CODEOWNERS
+  ✓ Require status checks: build, test, lint
+  ✓ Require branches up to date
+  ✓ Require signed commits
+  ✓ Restrict who can push: empty (force PR)
+  ✗ Allow force push: NEVER
+  ✗ Allow deletions: NEVER
+```
+
+### Pattern 7: Audit trail canônico
+
+```text
+Cada release tem audit trail completo:
+
+1. Commit message (what + why)
+2. PR description (context + breaking changes + migrations)
+3. PR reviewers (who approved)
+4. CI logs (build provenance + test results)
+5. Deploy logs (who triggered, when, which artifact)
+6. GitHub Release (changelog + tagged commit)
+7. Monitoring (SLO/golden signals during/after deploy)
+
+Tools:
+  - GitHub Releases — auto-generated changelog
+  - Sentry/Datadog — track release_id em events
+  - Slack/PagerDuty — notification em deploy
+  - SLSA attestation — provenance signed
+```
+
+## Anti-patterns
+
+### ANTI: aprovação humana manual em release
+
+```text
+ANTI: cada deploy → SRE checa, aprova, deploya manualmente.
+
+PROBLEMA: SRE bottleneck. Deploys raros (1×/semana). Velocity colapsa.
+          Toil para SRE.
+
+CERTO: policies em ferramenta. Engineer self-deploys. SRE escreve
+       guard rails (canary, SLO check), não aprovações ad-hoc.
+```
+
+### ANTI: deploy de branch local
+
+```text
+ANTI: dev faz `kubectl apply` da máquina dele.
+
+PROBLEMA: drift entre git e prod. Sem audit trail. Sem CI check.
+          Quando precisa rollback, "qual era a versão?".
+
+CERTO: deploy SOMENTE de CI. Local push to prod proibido em
+       branch protection. Pipeline valida + deploya + audit.
+```
+
+### ANTI: rollback "vai dar conta no forward-fix"
+
+```text
+ANTI: cultura "nunca rollback". Sempre forward-fix.
+
+PROBLEMA: forward-fix sob pressão = mais bugs. Rollback nunca
+          exercitado, quando precisa não funciona.
+
+CERTO: rollback < 5min em qualquer release, exercitado mensalmente.
+       Forward-fix é exception, não default.
+```
+
+### ANTI: schema migration NOT NULL sem default
+
+```text
+ANTI: ALTER TABLE orders ADD COLUMN priority INTEGER NOT NULL;
+
+PROBLEMA: migration falha em rows existentes. Rollback custoso.
+          Code novo + DB velho = error.
+
+CERTO: ADD COLUMN priority INTEGER DEFAULT 0 NOT NULL;
+       Forward-compatible (old code ignora; new code usa).
+       Rollback de code OK porque DB tem default.
+```
+
+### ANTI: feature flag sem expiration
+
+```text
+ANTI: flags acumulam, nunca removidas. 50 flags em prod, 30 ativas.
+
+PROBLEMA: cognitive load. Combinations untested. Flag Y desligado
+          há 6 meses ainda no código (dead code).
+
+CERTO: flags têm DATA DE EXPIRAÇÃO. Após launch + 30d safe → REMOVE
+       flag (e código do branch perdedor). Cleanup é parte da
+       feature, não opcional.
+```
+
+### ANTI: hotfix direct push em main
+
+```text
+ANTI: incident → dev pushar direto em main "pra ser rápido".
+
+PROBLEMA: bypass branch protection. Sem review. Sem CI.
+          Pode introduzir novo bug.
+
+CERTO: hotfix ainda via PR (mesmo se rápido — 5min review). CI
+       roda. Branch protection ativa. Audit trail preserved.
+       "Rápido" não é desculpa pra atalhar safety.
+```
+
+## Verificação
+
+1. Self-service deploy ativo (engineers deployam sozinhos)
+2. Trunk-based OR justified GitFlow exception
+3. Canary release pipeline (1% → 10% → 50% → 100% com SLO check)
+4. Rollback testado mensalmente; < 5 min
+5. Branch protection em main (no direct push, required PR + CI + reviewers)
+6. CODEOWNERS para paths críticos
+7. Lockfile commitado + frozen-install em CI
+8. Build provenance via SLSA
+9. Config 12-factor (env vars, GitOps)
+10. Feature flags com expiration policy
+11. Audit trail completo (commit + PR + CI + deploy + monitoring)
+
+---
+
+## Ver também
+
+- [`_shared-sre/glossary.md`](../_shared-sre/glossary.md) — vocabulário (release pipeline, canary, rollback, etc.)
+- [`hermetic-builds`](../hermetic-builds/SKILL.md) (v1.11) — fundação técnica
+- [`production-readiness-review`](../production-readiness-review/SKILL.md) (v1.10) — PRR Axe 5 (Change Management)
+- [`eliminating-toil`](../eliminating-toil/SKILL.md) (v1.10) — manual deployment é toil clássico
+- [`release-pipeline-auditor`](../../agents/release-pipeline-auditor.md) (v1.11) — agent que audita
+- [`/auditar-release`](../../commands/auditar-release.md) (v1.11) — comando
+- [`/concluir-marco`](../../commands/concluir-marco.md) (framework + patch v1.11) — gate `release-pipeline-policy` opt-in
+
+*Material-fonte: Site Reliability Engineering — Beyer/Jones/Petoff/Murphy (Google/O'Reilly, 2016) — Cap 8: "Release Engineering". Plus 12-factor app (12factor.net), DORA metrics.*