Post-Deploy Canary Monitor — Vigia Producao Sem Dormir

Inspiracao: gstack/canary (MIT, Garry Tan). Adaptado: foca em pos-deploy (depois do 100% rollout), enquanto skill 43 cobre durante o rollout gradual.

Diferenca vs skill 43 (canary-deployment)

Quando Usar

• deploy acabou de fechar 100% — primeiras 2-24h de vigilancia
• mudanca grande (migration, refactor, framework upgrade) que pode regredir silencioso
• sem observability robusta no projeto (esta skill cobre o basico)
• producao critica onde "deploy passou no canary 5%" nao garante "100% e saudavel"

Quando NAO Usar

• voce ja tem Datadog/Sentry/NewRelic com alertas — use o sistema existente
• deploy trivial (config change, doc) sem risco
• ainda esta no rollout — use skill 43

Governanca Global

Segue GLOBAL.md, policies/verification-before-completion.md (a verificacao continua apos deploy fechar), policies/handoffs.md (escalacao pra skill 43), policies/observability-trace-tags.md.

Gate contra constituicao

Quando memory/constitution.md define SLOs no eixo Performance/Reliability:

• baseline pre-deploy precisa estar capturado antes desta skill comecar
• threshold de abort = SLO violado + N% margem
• error budget restante deve cobrir esta janela de observacao

Inputs

url: https://prod.exemplo.com
baseline:
  metrics: ./baseline/metrics-pre-deploy.json
  screenshots: ./baseline/screenshots/
thresholds:
  console_errors_per_min: 0          # zero tolerancia
  lcp_regression_pct: 20              # >20% pior que baseline = abort
  cls_regression_pct: 25
  screenshot_diff_pct: 5              # >5% de pixels diferentes em paginas-chave
  status_5xx_pct: 1                   # >1% de respostas 5xx
window:
  interval: 15m
  duration: 24h
  abort_after_consecutive_failures: 2
escalation:
  on_abort: skill-43-rollback         # ou comando manual
  notify: <slack-channel | email>

Protocolo

1. Captura baseline (pre-deploy)

Se nao houver baseline ainda, capturar antes do deploy:

# Metricas
curl -s "$URL/metrics" > baseline/metrics-pre-deploy.json

# Screenshots de paginas-chave (Playwright via anthropic-skills:webapp-testing)
# - homepage
# - 2-3 paginas mais traficadas
# - 1 fluxo critico (checkout, login, search)

2. Loop de vigilancia (pos-deploy)

A cada interval (default 15min), por ate duration (default 24h):

1. Coletar metricas atuais — mesmo endpoint do baseline
2. Tirar screenshots atuais — mesmas paginas
3. Comparar contra baseline:
   • delta de console errors (qualquer >0 = alerta imediato)
   • delta de LCP/CLS (>threshold = alerta)
   • diff de screenshot (>threshold pixels = alerta)
   • taxa de 5xx (>threshold = alerta)
4. Registrar em docs/canary-runs/YYYY-MM-DD-<release>/timeline.jsonl:

{"t":"15:00","status":"ok","lcp_delta":-2,"errors":0,"screenshot_diff":0.4}
{"t":"15:15","status":"ok","lcp_delta":+5,"errors":0,"screenshot_diff":0.6}
{"t":"15:30","status":"alert","lcp_delta":+22,"errors":3,"screenshot_diff":7.2,"reason":"lcp_regression+errors"}

5. Decidir:
   • tudo verde → continuar ate fim da janela → mark healthy
   • 1 alerta → log e continuar (false-positive comum)
   • 2 alertas consecutivos → escalar abort

3. Escalacao em abort

Ao detectar 2 falhas consecutivas:

1. Registrar evento detalhado em docs/canary-runs/.../abort.md
2. Notificar canal configurado (slack/email)
3. Sugerir:
   • opcao A: /run-program rollback ou skill 43 reverse
   • opcao B: investigar (skill 06 + skill 34) — se nao for security/perf, hotfix
   • opcao C: user override (false positive confirmado)

NAO faz rollback automatico por default. Producao = decisao humana, salvo override explicito no input.

Checkpoint na opcao C: "false positive confirmado" exige o humano ter olhado a evidencia especifica do alerta (screenshot diff, log de erro), nao so aceitar a sugestao pra destravar o monitoramento. Se o override for aceito sem essa confirmacao, registrar isso explicitamente no abort.md — silenciar um alerta real vira o proximo incidente sem trace de por que passou.

4. Saida saudavel

Ao final da janela sem aborts:

1. Mark release healthy em docs/canary-runs/.../verdict.md
2. Atualizar docs/releases/<versao>.md com link pro report
3. Sugerir promover baseline atual como novo baseline canonico

Output canonico

docs/canary-runs/2026-05-27-v2.19.0/
├── input.yaml           # config usada
├── baseline/
│   ├── metrics.json
│   └── screenshots/
├── timeline.jsonl       # 1 linha por check
├── abort.md (se houve)  # detalhes do incidente
└── verdict.md           # healthy | rolled-back | aborted

Handoffs

• escalacao: skill 43 (canary-deployment reverso) ou skill 24 (release-manager)
• investigacao pos-abort: skill 06 (security) + skill 34 (static-analysis) + skill debugger
• registro pos-saudavel: skill 24 (release-manager) atualiza changelog com badge "verified"

Dependencias

• anthropic-skills:webapp-testing (Playwright) — captura screenshots
• skill 20 (observability-sre) — define o que metrificar
• skill 43 (canary-deployment) — escalacao de rollback
• skill 30 (cost-tracker) — esta skill consome recursos durante a janela

Anti-padroes

• ❌ Rollback automatico sem decisao humana (default) — producao nao se rolla sozinha
• ❌ Janela infinita — sempre duration finito (24h-7d max)
• ❌ Ignorar console error porque "e so um warning" — qualquer aumento = sinal
• ❌ Sem baseline pre-deploy — comparacao impossivel
• ❌ Screenshot diff sem mascarar areas dinamicas (timestamps, randoms) — gera false positive
• ❌ Esta skill substituir observability profissional — ela cobre o gap, nao o ouro padrao