@luanpdd/kit-mcp 1.9.0 → 1.10.0

package/CHANGELOG.md

@@ -6,6 +6,92 @@ Format: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) · Versioning:
 
 ## [Unreleased]
 
+## [1.10.0] - 2026-05-07
+
+Milestone v1.10 — Suíte SRE Engagement: incorpora técnicas do livro *Site Reliability Engineering: How Google Runs Production Systems* (Beyer, Jones, Petoff, Murphy — Google/O'Reilly, 2016) ao kit-mcp. 32 REQs em 6 fases (Phases 36-41), distribuídos em 3 ondas: Núcleo SRE (Phases 36-38), Integração com suítes existentes (Phases 39-40), Gates QA + docs (Phase 41). Complementa a Suíte Observabilidade v1.9.0 (publicada 2026-05-06) e a Suíte Supabase v1.8.0 — juntas formam o stack production engineering do kit.
+
+### Adicionado — 6 skills SRE foundationais (Phase 36)
+
+Cada skill é auto-contida (sem `references/`), com frontmatter `description ≤ 200 chars`, template canônico de 5 seções (Quando usar / Regras absolutas / Patterns canônicos / Anti-patterns / Ver também), e cross-refs via Markdown link relativo.
+
+- `_shared-sre/glossary.md` — vocabulário canônico bilíngue (PT-BR↔EN): SLI, SLO, SLA, error budget, burn rate, toil, postmortem, blameless, PRR, golden signals (latency/traffic/errors/saturation), risk continuum, MTTR, MTBF. Lista anti-patterns explícitos (alert fatigue, hero culture, SLO 99.99%+, fixed-window error budget, blame culture, mean-only latency, monitoring causes não symptoms).
+- `sre-risk-management` — risk continuum (cap 3 livro Google SRE), 99.99% wisdom (user em 99% smartphone não distingue 99.99% vs 99.999%), error budget como balanço explícito risk × innovation, "as reliable as needs to be, no more".
+- `four-golden-signals` — Latency + Traffic + Errors + Saturation (cap 6), black-box vs white-box monitoring, distinção de latência success vs error, percentis vs mean (long tail), histograms com bucketing exponencial.
+- `eliminating-toil` — definição canônica de toil (manual, repetitivo, automatizável, tático, sem valor durável, escala linear), regra ≤ 50% (cap 5), padrões de automação, distinção toil vs overhead vs grungy work.
+- `blameless-postmortems` — template canônico 9 seções (Summary, Impact, Root Causes, Trigger, Resolution, Detection, Action Items, Lessons Learned, Timeline UTC), cultura blameless (cap 15), "no postmortem left unreviewed", Wheel of Misfortune para training.
+- `production-readiness-review` — checklist PRR (cap 32) — 6 axes: System architecture, Instrumentation/Metrics/Monitoring, Emergency response, Capacity planning, Change management, Performance — com 3 modelos de engagement: Simple PRR, Early Engagement, Frameworks/SRE Platform.
+
+### Adicionado — 4 agents SRE core (Phase 37)
+
+Cada agent inclui tabela `## Compatibilidade` por IDE (Full / Partial / Offline-only), preflight detection MCP no Step 0 quando aplicável, e frontmatter `tools:` com nomes canônicos.
+
+- `golden-signals-instrumenter` — especialização de `observability-instrumenter` (v1.9). Recebe código de serviço/Edge Function e retorna patches OTel com Latency=histogram bucketed exponencial, Traffic=counter por endpoint × method, Errors=counter por `error.type` enum 5-15 valores fechado (NUNCA `error.message`), Saturation=gauge resource-specific identificado explicitamente.
+- `toil-auditor` — analisa repo + git log ≤ 90d + scripts shell + comandos manuais documentados em README/runbooks. Retorna `.planning/TOIL-AUDIT.md` listando candidatos a automação com priorização P0/P1/P2 e ROI = freq × tempo / esforço.
+- `postmortem-writer` — recebe `--from-investigation <id>` (continuação de `incident-investigator` v1.9 — lê `.planning/investigations/<id>.md`) ou `--incident "<descrição>"` (standalone). Gera postmortem blameless seguindo template canônico de 9 seções em `.planning/postmortems/<id>.md`.
+- `prr-conductor` — conduz Production Readiness Review para serviço/feature. Lê schema (Supabase MCP), Edge Functions code, SLOs definidos (`.planning/slos/`), audit logs. Produz `PRR-REPORT.md` scored em 6 axes com gaps e action items priorizados (P0 blocker / P1 scheduled).
+
+### Adicionado — 6 commands SRE (Phase 38)
+
+- `/sre <subcommand>` — orquestrador único (análogo a `/supabase` v1.8 e `/observabilidade` v1.9); dispatch via `Task(subagent_type=...)` com sinônimos PT/EN para os 5 comandos abaixo.
+- `/golden-signals` — invoca `golden-signals-instrumenter` para serviço/Edge Function/fase; gera `GOLDEN-SIGNALS.md` por target com instrumentação OTel pronta.
+- `/auditar-toil` — invoca `toil-auditor`; gera `.planning/TOIL-AUDIT.md`.
+- `/postmortem` — invoca `postmortem-writer`; suporta flag `--from-investigation <id>` (continuar de investigation v1.9) ou `--incident "<descrição>"` (postmortem standalone).
+- `/prr` — invoca `prr-conductor` para serviço/feature; usa flag `--service <name>` ou `--feature <description>`; gera `PRR-REPORT.md`.
+- `/risk-budget` — exibe state atual de error budget vs risk continuum, citando SLOs definidos em v1.9 (lê `.planning/slos/`); aplica skill `sre-risk-management`.
+
+### Adicionado — 3 audit gates novos (Phase 41)
+
+Markdown specs em `gates/` com `## Check` em bash 3.2-portable (macOS default):
+
+- `gates/golden-signals-coverage.md` (blocking, pre-verify) — verifica código de serviço/Edge Function tocado em fase tem os 4 golden signals presentes (regex sobre `histogram | counter | gauge | saturation`). Skip gracefully em projetos content-only (sem `supabase/functions/` / `src/` / `lib/`).
+- `gates/postmortem-template-required.md` (blocking, pre-conclude) — em `/concluir-marco`, bloqueia se houve incident em `.planning/investigations/` sem `.planning/postmortems/` correspondente. `Status: INCONCLUSIVE` reconhecido como exceção (sem root cause = sem aprendizado a documentar). Princípio canônico: "no postmortem left unreviewed" (cap 15).
+- `gates/prr-checklist-coverage.md` (blocking, pre-verify) — verifica que `PRR-REPORT.md` em `.planning/prr/**/*.md` cobre os 6 axes do PRR (System architecture, Instrumentation, Emergency response, Capacity planning, Change management, Performance) — pular um axe = aprovação inválida (regra absoluta da skill `production-readiness-review`).
+
+### Adicionado — integração com Suíte Observabilidade v1.9 (Phase 39)
+
+- **Skill `event-based-slos` (v1.9)** ganha bloco "Risk continuum" cross-referenciando `sre-risk-management`; explica que target SLO é escolha explícita no continuum risk × innovation, não meta arbitrária.
+- **Agent `omm-auditor` (v1.9)** consulta `toil-auditor` para Capacidade 3 (Complexidade/Tech Debt). Score OMM-3 considera % de tempo em toil pelo time. Tabela 5-row Cap 3 (`< 15%` → 5 / `15-30%` → 4 / `30-50%` → 3 / `50-60%` → 2 / `> 60%` → 1) replicada como single source of truth distribuída.
+
+### Adicionado — integração com Suíte Supabase v1.8 (Phase 39)
+
+- **`supabase-edge-fn-writer`** ganha seção "Four Golden Signals" — template canônico de Edge Function inclui histogram de latência, counter de tráfego, counter de erros por error.type enum, gauge de saturação (recurso identificado explicitamente: pg_pool / concurrency_limit / pgmq.queue_length / egress_bandwidth conforme tipo de função).
+- **`supabase-architect`** ganha menção a PRR — plano arquitetural sugere PRR antes de production; cross-ref para `production-readiness-review`. Tabela 6 axes adaptada ao contexto Supabase (single project = SPOF mitigado por branches Pro; Spend Cap; RLS git-versioned; declarative schema; load test com p99 baseline).
+- **`supabase-migration-writer`** ganha alerta sobre toil — scripts SQL repetitivos (rebuild de índices manuais, vacuums recorrentes) são candidatos a automação via pg_cron; cross-ref para `eliminating-toil`.
+- **`supabase-storage-implementer`** ganha saturation signal — uploads emitem gauge de bucket size + counter de quota near-exhaustion (thresholds 80% yellow / 95% red por plan: Free 1 GB / Pro 100 GB / Team 1 TB / Enterprise custom); cross-ref para `four-golden-signals`.
+
+### Mudado — lifecycle hooks no fluxo framework (Phase 40)
+
+Patches editoriais puramente aditivos em 3 commands de fluxo framework — frontmatter (`description`, `allowed-tools`) preservado byte-a-byte (anti-pitfall A2), workflows em `.claude/framework/workflows/*.md` continuam funcionais como antes.
+
+- **`/forense`** ganha bloco `<sre_integration>` que sugere chain `/postmortem` automaticamente após Core Analysis Loop fechar com root cause `VALIDATED`. Distinção fundamental: forense diagnostica (read-only, evidence-based, científico — output em `.planning/forensics/`); postmortem documenta blameless para aprendizado organizacional (cap 15 — output em `.planning/postmortems/`). 3 condições de trigger sugerido + 3 exceções explícitas de não-trigger (INT-FW-V2-01).
+- **`/concluir-marco`** ganha gate PRR opcional — quando `workflow.complete_milestone_prr_gate=true` (default `false`, opt-in até maturidade SRE), exige `PRR-REPORT.md` com status `passed` para features production-bound antes de arquivar. Status table 3-row (`passed` 6/6 axes ≥ 3/5 = arquivável / `passed-with-warnings` P1 pendente = arquivável com warnings / `failed` P0 reprovado = BLOQUEIA). Coexiste ortogonalmente com gate OMM regression v1.9 — OMM mede observability maturity, PRR mede production readiness (INT-FW-V2-02).
+- **`/auditar-marco`** invoca `/auditar-toil` automaticamente quando `workflow.audit_milestone_toil=true` (default `true`); resultado `.planning/TOIL-AUDIT.md` alimenta scoring OMM Capacidade 3 via `omm-auditor`. Loop fechado canônico: `/auditar-marco` → `/auditar-toil` → `/auditar-observabilidade` → `omm-auditor` consulta `TOIL-AUDIT.md` → `OMM-REPORT.md` inclui Cap 3 → `MILESTONE-AUDIT.md` (INT-FW-V2-03).
+
+### Mudado — README ganha seção "SRE Engagement suite (v1.10)"
+
+`README.md` adiciona nova seção entre "Observability suite (v1.9)" e o separador `---` listando 6 skills + 4 agents + 6 commands + 3 audit gates + lifecycle integration + quick start example end-to-end (PRR antes de produção → instrumentação golden signals → após incident, postmortem chain). Citação canônica ao livro Google SRE 2016 em paridade com a citação a *Observability Engineering* na seção v1.9 (QA-SRE-04).
+
+### Sem mudanças de API runtime
+
+v1.10 é **content-only por design** — zero alterações em `src/core/`, `registry.js`, `sync.js`, ou no MCP server. Stable API v1.0+ totalmente preservada. CI passa sem mudança em `.github/workflows/`. Deps budget mantido em 6/6 (zero deps novas — todo o conteúdo é Markdown).
+
+### Tests
+
+Tests existentes (115 unit + 67 integration acumulados de v1.7) continuam verde. Novos gates não têm tests dedicados (são bash em markdown, executados via `runGate` no framework de gates já testado em `test/unit/gates.test.js`). Smoke validation por gate: PASS na codebase atual (kit-mcp content-only) + FAIL em fixture sintético com gaps + PASS em fixture sintético com cobertura completa — todos os 3 gates novos validados.
+
+### Decisões arquiteturais
+
+- **Conteúdo-only milestone** — zero alterações em `src/core/`. Toda integração com fluxo framework via patches editoriais nos commands `kit/commands/{forense,concluir-marco,auditar-marco}.md` (paridade com pattern v1.9 que adicionou bloco `<observability_integration>` aos mesmos commands).
+- **Specialização sobre overlap** — `golden-signals-instrumenter` é especialização de `observability-instrumenter` (v1.9), não substituto: aquele cuida de spans/atributos canônicos, este cuida de métricas dos 4 signals; ambos podem coexistir num mesmo PR (chain canônica: `observability-instrumenter` primeiro → `golden-signals-instrumenter` segundo).
+- **Chain v1.9 → v1.10** — `incident-investigator` (v1.9) fecha Core Analysis Loop com root cause `VALIDATED` em `.planning/investigations/<id>.md`; `postmortem-writer` (v1.10) consome via `--from-investigation <id>` para gerar `.planning/postmortems/<id>.md`. Handoff é state-based via filesystem (não API).
+- **Gates blocking pre-verify** — `golden-signals-coverage` e `prr-checklist-coverage` são blocking (cobertura mínima é regra absoluta). `postmortem-template-required` é blocking pre-conclude (regra cap 15 "no postmortem left unreviewed" não admite warn-only após adoption).
+- **PRR gate em `/concluir-marco` é opt-in** — diferente do gate OMM regression v1.9 (default `true`, estabelecido), o gate PRR v1.10 é default `false` até time amadurecer cultura SRE. Toggle via `workflow.complete_milestone_prr_gate=true`. Critério de "ligar gate": ≥ 2 dos 4 indicadores (paid feature, SLO definido, on-call rotation, postmortem culture).
+- **Vendor-neutral** — gate `golden-signals-coverage` aceita qualquer pattern com `histogram` / `counter` / `gauge` (OTel, Prometheus, StatsD, Borgmon-like). Livro Google SRE descreve Borgmon mas é proprietário; gate é genérico.
+
+### Detalhes
+
+`.planning/milestones/v1.10.0/` (após `/concluir-marco`).
+
 ## [1.8.1] - 2026-05-06
 
 Patch de integração da Suíte Supabase v1.8.0 — fecha 7 lacunas onde o conteúdo novo não estava "wired" nos pontos de entrada existentes do framework.

package/README.md

@@ -101,6 +101,64 @@ A complete observability layer derived from *Observability Engineering* (Charity
 /observabilidade omm
 ```
 
+### SRE Engagement suite (v1.10)
+
+A production engineering layer derived from *Site Reliability Engineering: How Google Runs Production Systems* (Beyer, Jones, Petoff, Murphy — Google/O'Reilly, 2016) ships in the kit. It composes with the Supabase suite (v1.8) and the Observability suite (v1.9) into a coherent production engineering stack — Supabase agents now suggest PRR before launch, every Edge Function template includes the **4 golden signals**, and `incident-investigator` outputs feed directly into blameless postmortems via `/postmortem --from-investigation <id>`.
+
+**6 skills** in `kit/skills/`:
+- `_shared-sre/glossary.md` — canonical bilingual vocabulary (PT-BR↔EN) — SLI/SLO/SLA, error budget, burn rate, toil, postmortem, blameless, PRR, golden signals, risk continuum, MTTR/MTBF
+- `sre-risk-management` — risk continuum (cap 3), 99.99% wisdom ("as reliable as needs to be, no more"), error budget as explicit risk × innovation balance
+- `four-golden-signals` — Latency + Traffic + Errors + Saturation (cap 6), histograms with exponential bucketing, success vs error latency separated, percentiles vs mean (long tail)
+- `eliminating-toil` — canonical toil definition (manual + repetitive + automatable + tactical + no enduring value + scales linearly), ≤ 50% rule (cap 5), automation patterns
+- `blameless-postmortems` — canonical 9-section template (cap 15), "no postmortem left unreviewed", blame culture as anti-pattern, Wheel of Misfortune
+- `production-readiness-review` — PRR checklist (cap 32) — 6 axes (System architecture, Instrumentation, Emergency response, Capacity planning, Change management, Performance), 3 engagement models
+
+**4 agents** in `kit/agents/`:
+- `golden-signals-instrumenter` — specialization of `observability-instrumenter` (v1.9); generates OTel patches with the 4 golden signals (Latency=histogram, Traffic=counter, Errors=counter by `error.type`, Saturation=gauge)
+- `toil-auditor` — analyzes git log + shell scripts + manual commands in README/runbooks; produces `TOIL-AUDIT.md` with P0/P1/P2 priority + estimated effort
+- `postmortem-writer` — natural continuation of `incident-investigator` (v1.9); reads `.planning/investigations/<id>.md` and produces blameless postmortem (Summary, Impact, Root Causes, Trigger, Resolution, Detection, Action Items, Lessons Learned, Timeline UTC)
+- `prr-conductor` — conducts Production Readiness Review for service/feature; reads schema (Supabase MCP), Edge Functions, `.planning/slos/`, audit logs; produces `PRR-REPORT.md` scored across the 6 axes
+
+**6 commands**:
+- `/sre <subcommand>` — single orchestrator (analog to `/supabase` v1.8 and `/observabilidade` v1.9) — dispatches to the 4 agents with PT/EN synonyms
+- `/golden-signals` — invokes `golden-signals-instrumenter` for service/Edge Function/phase; generates `GOLDEN-SIGNALS.md` with OTel-ready instrumentation
+- `/auditar-toil` — invokes `toil-auditor`; generates `.planning/TOIL-AUDIT.md`
+- `/postmortem` — invokes `postmortem-writer`; supports `--from-investigation <id>` (continue from v1.9 investigation) or `--incident "<description>"` (standalone)
+- `/prr` — invokes `prr-conductor`; supports `--service <name>` or `--feature <description>`; generates `PRR-REPORT.md`
+- `/risk-budget` — displays current error budget vs risk continuum, citing SLOs from v1.9 (`.planning/slos/`); applies `sre-risk-management` skill
+
+**3 audit gates** in `gates/`:
+- `golden-signals-coverage` (blocking, pre-verify) — verifies code in `supabase/functions/**`, `src/**`, `lib/**` covers the 4 golden signals (skips gracefully on content-only phases)
+- `postmortem-template-required` (blocking, pre-conclude) — blocks `/concluir-marco` if any `.planning/investigations/<id>.md` lacks a corresponding `.planning/postmortems/<id>.md` (`Status: INCONCLUSIVE` is the only exception)
+- `prr-checklist-coverage` (blocking, pre-verify) — verifies every `PRR-REPORT.md` in `.planning/prr/**/*.md` covers the 6 canonical axes; "skipping an axe = invalid approval"
+
+**Lifecycle integration:**
+- `/forense` — after Core Analysis Loop closes with VALIDATED root cause, suggests chain `/postmortem --from-investigation <id>` (Phase 40 / INT-FW-V2-01)
+- `/concluir-marco` — opt-in gate `workflow.complete_milestone_prr_gate=true` requires `PRR-REPORT.md` with status `passed` for production-bound features before archive (Phase 40 / INT-FW-V2-02)
+- `/auditar-marco` — auto-invokes `/auditar-toil` when `workflow.audit_milestone_toil=true` (default); result feeds OMM Capacidade 3 scoring via `omm-auditor` (Phase 40 / INT-FW-V2-03)
+
+**Quick start example — end-to-end SRE workflow:**
+```bash
+# Before launching a new feature in production — PRR
+/sre prr --feature "checkout v2"
+
+# While instrumenting service — apply 4 golden signals
+/sre golden-signals supabase/functions/orders/index.ts
+
+# Audit team toil quarterly
+/sre toil
+
+# When SLO burn alert fires — investigate (v1.9 deep loop), then postmortem (v1.10)
+/investigar-producao "checkout SLO burn rate = 8 às 14:32"
+/sre postmortem --from-investigation checkout-2026-05-07
+# Or for framework-level failures:
+/forense "framework workflow X falhou em produção"
+/sre postmortem --incident "framework workflow X failed (see .planning/forensics/report-*)"
+
+# Risk dashboard against SLO budgets
+/sre risk-budget
+```
+
 ---
 
 ## Prerequisites

package/gates/golden-signals-coverage.md

@@ -0,0 +1,133 @@
+---
+id: golden-signals-coverage
+stage: pre-verify
+blocking: true
+description: Valida que código de serviço/Edge Function tocado em fase contém os 4 golden signals (Latency=histogram, Traffic=counter, Errors=counter, Saturation=gauge). Skip se fase só toca markdown.
+---
+
+# Golden signals coverage gate
+
+**When to run:** pre-verify (blocking — fase não verifica até cobertura completa).
+
+## Check
+
+```bash
+#!/usr/bin/env bash
+# PT-BR: validar que código de serviço/Edge Function tocado em fase tem 4 golden signals.
+# Estratégia: descobrir arquivos tocados (supabase/functions/** ou STATE.md current_phase code paths),
+# rodar grep por histogram/counter/gauge/saturation, contar matches por sinal.
+# Bash 3.2-portable (macOS default).
+set -e
+
+# PT-BR: identificar fase atual via STATE.md
+STATE_FILE=".planning/STATE.md"
+CURRENT_PHASE=""
+if [ -f "$STATE_FILE" ]; then
+  CURRENT_PHASE=$(grep -E "^Fase:" "$STATE_FILE" 2>/dev/null | head -1 | sed -E 's/^Fase: *([0-9]+).*/\1/')
+fi
+
+# PT-BR: candidatos a arquivos de código tocados — escopo principal Supabase Edge + qualquer .ts/.js/.py
+# em paths declarados pela fase (heurística: supabase/functions/** SEMPRE inspecionado).
+CODE_FILES=""
+if [ -d "supabase/functions" ]; then
+  CODE_FILES=$(find supabase/functions -type f \( -name "*.ts" -o -name "*.js" -o -name "*.mjs" \) 2>/dev/null)
+fi
+
+# PT-BR: também inspecionar lib/ e src/ se existirem (apps Node/Deno fora de Supabase)
+if [ -d "src" ]; then
+  ADDITIONAL=$(find src -type f \( -name "*.ts" -o -name "*.js" -o -name "*.mjs" -o -name "*.py" \) 2>/dev/null)
+  CODE_FILES="$CODE_FILES
+$ADDITIONAL"
+fi
+if [ -d "lib" ]; then
+  ADDITIONAL=$(find lib -type f \( -name "*.ts" -o -name "*.js" -o -name "*.mjs" -o -name "*.py" \) 2>/dev/null)
+  CODE_FILES="$CODE_FILES
+$ADDITIONAL"
+fi
+
+# PT-BR: filtrar linhas vazias
+CODE_FILES=$(echo "$CODE_FILES" | grep -v "^$" || true)
+
+# PT-BR: se fase não toca código (só markdown/docs), pular gate
+if [ -z "$CODE_FILES" ]; then
+  echo "INFO: nenhum arquivo de código (.ts/.js/.py) encontrado em supabase/functions/** | src/** | lib/** — fase parece content-only. Gate skipped."
+  exit 0
+fi
+
+# PT-BR: contar matches por signal
+LATENCY_HITS=0
+TRAFFIC_HITS=0
+ERRORS_HITS=0
+SATURATION_HITS=0
+
+# PT-BR: process file list line-by-line para portabilidade bash 3.2
+OLDIFS="$IFS"
+IFS='
+'
+for f in $CODE_FILES; do
+  [ -z "$f" ] && continue
+  [ ! -f "$f" ] && continue
+
+  # PT-BR: Latency = histogram (createHistogram, recordHistogram, histogram.record)
+  if grep -qE "histogram|Histogram" "$f" 2>/dev/null; then
+    LATENCY_HITS=$((LATENCY_HITS + 1))
+  fi
+
+  # PT-BR: Traffic + Errors = counter (Errors counter dimensionado por error.type)
+  if grep -qE "counter|Counter|createCounter" "$f" 2>/dev/null; then
+    TRAFFIC_HITS=$((TRAFFIC_HITS + 1))
+    ERRORS_HITS=$((ERRORS_HITS + 1))
+  fi
+
+  # PT-BR: Saturation = gauge (createObservableGauge, gauge.record) ou string saturation
+  if grep -qE "gauge|Gauge|saturation|Saturation" "$f" 2>/dev/null; then
+    SATURATION_HITS=$((SATURATION_HITS + 1))
+  fi
+done
+IFS="$OLDIFS"
+
+# PT-BR: gate passa se TODOS os 4 signals têm pelo menos 1 hit em algum arquivo de código
+MISSING=""
+[ "$LATENCY_HITS" -eq 0 ] && MISSING="$MISSING Latency(histogram)"
+[ "$TRAFFIC_HITS" -eq 0 ] && MISSING="$MISSING Traffic(counter)"
+[ "$ERRORS_HITS" -eq 0 ] && MISSING="$MISSING Errors(counter)"
+[ "$SATURATION_HITS" -eq 0 ] && MISSING="$MISSING Saturation(gauge)"
+
+if [ -z "$MISSING" ]; then
+  echo "PASS: 4 golden signals cobertos em código (Latency=$LATENCY_HITS files / Traffic=$TRAFFIC_HITS / Errors=$ERRORS_HITS / Saturation=$SATURATION_HITS)"
+  exit 0
+else
+  echo "FAIL: golden signals ausentes em código tocado:$MISSING"
+  echo "Sugestão: rodar /sre golden-signals <service> ou /golden-signals para gerar instrumentação OTel canônica."
+  echo "Cross-ref: kit/skills/four-golden-signals/SKILL.md + kit/agents/golden-signals-instrumenter.md"
+  exit 1
+fi
+```
+
+## Verdict
+
+- **passed** — todos 4 signals (Latency / Traffic / Errors / Saturation) presentes em pelo menos 1 arquivo de código no projeto
+- **passed (skip)** — projeto não tem código (apenas markdown / docs); gate não aplicável
+- **block** — pelo menos 1 signal ausente em código tocado pela fase
+
+## Why
+
+O livro Google SRE (cap 6 — *Monitoring Distributed Systems*) define os **4 golden signals** como cobertura mínima universal de saúde operacional para serviços user-facing — Latency (histogram com percentis, success vs error separados), Traffic (counter por endpoint × method), Errors (counter por `error.type` enum 5-15 valores, NUNCA `error.message`), Saturation (gauge do recurso mais escasso identificado explicitamente).
+
+Sem esse gate, fases entregam Edge Functions / serviços sem instrumentação básica e dashboards crescem ad-hoc (CPU, memory, threads — *causes* não *symptoms*). Gate força padrão canônico: cada PR de código deve cobrir os 4 signals, ou explicar a ausência via skip (fase só altera markdown).
+
+Cross-ref agent canônico: [`golden-signals-instrumenter`](../kit/agents/golden-signals-instrumenter.md) (Phase 37 / AGCORE-SRE-01). Skill: [`four-golden-signals`](../kit/skills/four-golden-signals/SKILL.md) (Phase 36 / SKFD-SRE-02).
+
+## REQ
+
+QA-SRE-01.
+
+## Configuração
+
+Gate é **blocking** por default. Para tornar warn-only (durante adoption inicial em legado):
+
+```bash
+node ./.claude/framework/bin/tools.cjs config-set workflow.golden_signals_coverage_warn true
+```
+
+(Nota: implementação do toggle warn-only é deferida — gate atual lê apenas presença/ausência de regex, não consulta config.)

package/gates/postmortem-template-required.md

@@ -0,0 +1,127 @@
+---
+id: postmortem-template-required
+stage: pre-conclude
+blocking: true
+description: Bloqueia /concluir-marco se há investigação em .planning/investigations/ sem postmortem correspondente em .planning/postmortems/. "No postmortem left unreviewed" (cap 15).
+---
+
+# Postmortem template required gate
+
+**When to run:** pre-conclude (blocking — milestone NÃO arquiva até cada incident ter postmortem blameless).
+
+## Check
+
+```bash
+#!/usr/bin/env bash
+# PT-BR: validar que cada investigação em .planning/investigations/ tem postmortem em .planning/postmortems/.
+# Match por basename (sem extensão .md). Investigations com Status: INCONCLUSIVE são exceção.
+# Bash 3.2-portable (macOS default).
+set -e
+
+INV_DIR=".planning/investigations"
+PM_DIR=".planning/postmortems"
+
+# PT-BR: se não há investigations, gate passa com INFO
+if [ ! -d "$INV_DIR" ]; then
+  echo "INFO: $INV_DIR não existe — projeto sem incidents registrados. Gate skipped."
+  exit 0
+fi
+
+# PT-BR: listar investigations (single-file *.md OR subdir com STATE.md)
+INVESTIGATIONS=""
+
+# PT-BR: pattern A — .planning/investigations/<id>.md (single file)
+SINGLE_FILES=$(find "$INV_DIR" -maxdepth 1 -type f -name "*.md" 2>/dev/null || true)
+if [ -n "$SINGLE_FILES" ]; then
+  INVESTIGATIONS="$INVESTIGATIONS
+$SINGLE_FILES"
+fi
+
+# PT-BR: pattern B — .planning/investigations/<id>/STATE.md (subdir state)
+SUBDIR_STATES=$(find "$INV_DIR" -mindepth 2 -maxdepth 2 -type f -name "STATE.md" 2>/dev/null || true)
+if [ -n "$SUBDIR_STATES" ]; then
+  INVESTIGATIONS="$INVESTIGATIONS
+$SUBDIR_STATES"
+fi
+
+# PT-BR: filtrar linhas vazias
+INVESTIGATIONS=$(echo "$INVESTIGATIONS" | grep -v "^$" || true)
+
+if [ -z "$INVESTIGATIONS" ]; then
+  echo "INFO: $INV_DIR vazio — sem incidents registrados. Gate skipped."
+  exit 0
+fi
+
+# PT-BR: para cada investigation, extrair <id> e checar postmortem correspondente
+MISSING=0
+MISSING_LIST=""
+OLDIFS="$IFS"
+IFS='
+'
+for inv_path in $INVESTIGATIONS; do
+  [ -z "$inv_path" ] && continue
+  [ ! -f "$inv_path" ] && continue
+
+  # PT-BR: extrair <id> — basename sem .md OU dirname se for STATE.md em subdir
+  base=$(basename "$inv_path")
+  if [ "$base" = "STATE.md" ]; then
+    # pattern B — id é o nome do subdir parent
+    id=$(basename "$(dirname "$inv_path")")
+  else
+    # pattern A — id é basename sem .md
+    id="${base%.md}"
+  fi
+
+  # PT-BR: se investigation tem Status: INCONCLUSIVE (sem root cause), pular
+  if grep -qiE "^Status:.*INCONCLUSIVE|^.*Status.*INCONCLUSIVE" "$inv_path" 2>/dev/null; then
+    echo "INFO: investigation '$id' marcada INCONCLUSIVE — sem root cause, postmortem não exigido."
+    continue
+  fi
+
+  # PT-BR: postmortem esperado em .planning/postmortems/<id>.md
+  pm_path="$PM_DIR/$id.md"
+  if [ ! -f "$pm_path" ]; then
+    MISSING=$((MISSING + 1))
+    MISSING_LIST="$MISSING_LIST $id"
+  fi
+done
+IFS="$OLDIFS"
+
+if [ "$MISSING" -eq 0 ]; then
+  echo "PASS: todas as investigações têm postmortem correspondente em $PM_DIR/"
+  exit 0
+else
+  echo "FAIL: $MISSING investigação(ões) sem postmortem em $PM_DIR/:$MISSING_LIST"
+  echo "Sugestão: rodar /postmortem --from-investigation <id> para cada item ausente."
+  echo "Cross-ref: kit/skills/blameless-postmortems/SKILL.md + kit/agents/postmortem-writer.md"
+  echo "Princípio canônico: 'No postmortem left unreviewed' (cap 15 livro Google SRE)."
+  exit 1
+fi
+```
+
+## Verdict
+
+- **passed** — todas investigations têm postmortem correspondente OR investigations marcadas INCONCLUSIVE OR diretório `.planning/investigations/` ausente
+- **block** — pelo menos 1 investigation sem postmortem em `.planning/postmortems/`
+
+## Why
+
+O livro Google SRE (cap 15 — *Postmortem Culture: Learning from Failure*) define como princípio canônico **"no postmortem left unreviewed"**: cada incident significativo (registrado como investigação via `/forense` + `incident-investigator` v1.9) deve gerar postmortem blameless documentando *o que aprendemos* e *o que mudaremos*.
+
+Sem este gate, milestones arquivam com investigations órfãs — root cause foi diagnosticado mas aprendizado organizacional perdeu-se (anti-pattern hero culture: "fixei o bug, vamos seguir"). Gate força a chain canônica entre v1.9 (Core Analysis Loop diagnostica) e v1.10 (postmortem documenta).
+
+Cross-ref agent canônico: [`postmortem-writer`](../kit/agents/postmortem-writer.md) (Phase 37 / AGCORE-SRE-03). Skill: [`blameless-postmortems`](../kit/skills/blameless-postmortems/SKILL.md) (Phase 36 / SKFD-SRE-04). Comando: `/postmortem --from-investigation <id>` (Phase 38 / CMD-SRE-03). Chain documentado em `kit/commands/forense.md` bloco `<sre_integration>` (Plan 40-01 / INT-FW-V2-01).
+
+## REQ
+
+QA-SRE-02.
+
+## Configuração
+
+Gate é **blocking** por default (cultura SRE blameless é não-negociável uma vez instituída). Para tornar warn-only durante adoption inicial:
+
+```bash
+node ./.claude/framework/bin/tools.cjs config-set workflow.postmortem_required_warn true
+```
+
+(Nota: implementação do toggle warn-only é deferida — gate atual lê apenas presença/ausência de pares investigation↔postmortem, não consulta config.)

package/gates/prr-checklist-coverage.md

@@ -0,0 +1,128 @@
+---
+id: prr-checklist-coverage
+stage: pre-verify
+blocking: true
+description: Valida que cada PRR-REPORT.md em .planning/prr/ cobre os 6 axes canonicos (System Architecture/Instrumentation/Emergency/Capacity/Change/Performance — cap 32 livro Google SRE).
+---
+
+# PRR checklist coverage gate
+
+**When to run:** pre-verify (blocking — PRR sem 6 axes = aprovação inválida).
+
+## Check
+
+```bash
+#!/usr/bin/env bash
+# PT-BR: validar que cada PRR-REPORT.md em .planning/prr/**/*.md cobre os 6 axes do PRR.
+# Match por palavra-chave em heading H2 (case-insensitive). Pular um axe = aprovação inválida.
+# Bash 3.2-portable (macOS default).
+set -e
+
+PRR_DIR=".planning/prr"
+
+# PT-BR: se não há PRR reports, gate passa com INFO
+if [ ! -d "$PRR_DIR" ]; then
+  echo "INFO: $PRR_DIR não existe — projeto sem PRR reports. Gate skipped."
+  exit 0
+fi
+
+# PT-BR: listar todos os *.md em .planning/prr/ recursivamente
+PRR_FILES=$(find "$PRR_DIR" -type f -name "*.md" 2>/dev/null || true)
+PRR_FILES=$(echo "$PRR_FILES" | grep -v "^$" || true)
+
+if [ -z "$PRR_FILES" ]; then
+  echo "INFO: $PRR_DIR vazio — sem PRR reports. Gate skipped."
+  exit 0
+fi
+
+# PT-BR: para cada PRR report, validar que cobre os 6 axes
+VIOLATIONS=0
+OLDIFS="$IFS"
+IFS='
+'
+for prr_file in $PRR_FILES; do
+  [ -z "$prr_file" ] && continue
+  [ ! -f "$prr_file" ] && continue
+
+  # PT-BR: extrair headings H2 (case-insensitive)
+  H2=$(grep -E "^## " "$prr_file" 2>/dev/null || true)
+
+  # PT-BR: 6 axes — match em palavras-chave (qualquer variante aceitável)
+  AXE_MISSING=""
+
+  # Axe 1: System Architecture
+  if ! echo "$H2" | grep -qiE "system.*architecture|architecture"; then
+    AXE_MISSING="$AXE_MISSING Axe1(SystemArchitecture)"
+  fi
+
+  # Axe 2: Instrumentation / Metrics / Monitoring
+  if ! echo "$H2" | grep -qiE "instrumentation|metrics|monitoring"; then
+    AXE_MISSING="$AXE_MISSING Axe2(Instrumentation)"
+  fi
+
+  # Axe 3: Emergency Response
+  if ! echo "$H2" | grep -qiE "emergency.*response|emergency"; then
+    AXE_MISSING="$AXE_MISSING Axe3(EmergencyResponse)"
+  fi
+
+  # Axe 4: Capacity Planning
+  if ! echo "$H2" | grep -qiE "capacity.*planning|capacity"; then
+    AXE_MISSING="$AXE_MISSING Axe4(CapacityPlanning)"
+  fi
+
+  # Axe 5: Change Management
+  if ! echo "$H2" | grep -qiE "change.*management|change"; then
+    AXE_MISSING="$AXE_MISSING Axe5(ChangeManagement)"
+  fi
+
+  # Axe 6: Performance
+  if ! echo "$H2" | grep -qiE "performance"; then
+    AXE_MISSING="$AXE_MISSING Axe6(Performance)"
+  fi
+
+  if [ -n "$AXE_MISSING" ]; then
+    echo "FAIL: $prr_file — axes ausentes:$AXE_MISSING"
+    VIOLATIONS=$((VIOLATIONS + 1))
+  fi
+done
+IFS="$OLDIFS"
+
+if [ "$VIOLATIONS" -eq 0 ]; then
+  total=$(echo "$PRR_FILES" | wc -l | tr -d ' ')
+  echo "PASS: $total PRR-REPORT(s) cobrem os 6 axes canônicos"
+  exit 0
+else
+  echo "FAIL: $VIOLATIONS PRR-REPORT(s) com axes ausentes"
+  echo "Sugestão: rodar /sre prr <service> ou /prr para regenerar com template canônico (6 axes obrigatórios)."
+  echo "Cross-ref: kit/skills/production-readiness-review/SKILL.md + kit/agents/prr-conductor.md"
+  echo "Princípio canônico: 'Pular um axe = aprovação inválida' (cap 32 livro Google SRE)."
+  exit 1
+fi
+```
+
+## Verdict
+
+- **passed** — cada PRR-REPORT.md em `.planning/prr/**/*.md` tem H2 cobrindo os 6 axes (System Architecture / Instrumentation / Emergency Response / Capacity Planning / Change Management / Performance) OR diretório `.planning/prr/` ausente
+- **block** — pelo menos 1 PRR-REPORT.md com axe(s) ausente(s)
+
+## Why
+
+O livro Google SRE (cap 32 — *Evolving SRE Engagement Model*) define **6 axes canônicos** do Production Readiness Review. A skill `production-readiness-review` (Phase 36 / SKFD-SRE-05) declara como regra absoluta: *"Pular um axe = aprovação inválida (lacuna oculta vira incident em 6 meses)"*.
+
+Sem este gate, PRRs apressados podem omitir axes "menos relevantes" (anti-pattern documentado na skill); gaps em Change Management ou Capacity Planning não detectados em PRR viram incidents em produção meses depois. Gate força padrão canônico — cada `PRR-REPORT.md` cobrindo os 6 axes integralmente, mesmo que items dentro de um axe sejam N/A para o serviço (justificativa explícita no item, não no axe).
+
+Cross-ref agent canônico: [`prr-conductor`](../kit/agents/prr-conductor.md) (Phase 37 / AGCORE-SRE-04). Skill: [`production-readiness-review`](../kit/skills/production-readiness-review/SKILL.md) (Phase 36 / SKFD-SRE-05). Comando: `/prr --service <name>` ou `/prr --feature <description>` (Phase 38 / CMD-SRE-04).
+
+## REQ
+
+QA-SRE-03.
+
+## Configuração
+
+Gate é **blocking** por default. Para tornar warn-only durante adoption inicial:
+
+```bash
+node ./.claude/framework/bin/tools.cjs config-set workflow.prr_checklist_coverage_warn true
+```
+
+(Nota: implementação do toggle warn-only é deferida — gate atual não consulta config.)