Files
ealmeida faef9b47dc fix(project-manager): remover Dify KB das descriptions, marcar nota TODO
Dify foi removido 06-03-2026. Skills brainstorm/discover ainda referenciam-no
no corpo. Bump v1.2 + nota top-of-file. Reescrita workflow para próxima sessão.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-07 04:52:03 +01:00

3.5 KiB

name, description
name description
canary Monitorização pós-deploy — detecta regressões em produção. Verifica que o deploy não quebrou nada crítico nos 15min seguintes. Baseado no gstack /canary. Eixo 2B. Usar após qualquer deploy em produção.

/canary — Monitorização Pós-Deploy

Os primeiros 15 minutos após um deploy são os mais críticos. Esta skill verifica que tudo está OK.


Quando Usar (SEMPRE após deploy produção)

  • Após deploy de código em produção
  • Após actualização de WordPress (core, plugins, temas)
  • Após alterações de servidor (PHP, Nginx, MySQL)
  • Após mudanças de DNS ou SSL
  • Após activação de nova funcionalidade

Protocolo (15 minutos)

Minuto 0-2 — Status Checks

# 1. Site responde?
curl -s -o /dev/null -w "%{http_code}" <URL>/
# Esperado: 200

# 2. Admin WP responde?
curl -s -o /dev/null -w "%{http_code}" <URL>/wp-admin/
# Esperado: 200 ou 302

# 3. SSL válido?
curl -vI <URL> 2>&1 | grep "SSL certificate verify"
# Esperado: SSL certificate verify ok

# 4. Tempo de resposta aceitável?
curl -s -o /dev/null -w "%{time_total}\n" <URL>/
# Esperado: < 3.0 segundos

Minuto 2-5 — Funcionalidades Críticas

Para WordPress:

# Página principal carrega sem erros
curl -s <URL>/ | grep -c "wp-content"
# Esperado: > 0

# Sem erro crítico PHP
curl -s <URL>/ | grep -i "fatal error\|parse error\|warning"
# Esperado: sem output

# WP-CLI status
wp --path=/var/www/html core verify-checksums 2>&1 | tail -1
# Esperado: "WordPress installation verifies against checksums."

Para aplicações:

# Health endpoint
curl -s <URL>/api/health | jq '.status'
# Esperado: "ok"

# Database conecta?
curl -s <URL>/api/health | jq '.database'
# Esperado: "connected"

Minuto 5-10 — Métricas de Performance

// Via Lighthouse MCP
mcp__lighthouse__get_performance_score({ url: "<URL>" })
// Esperado: >= baseline (ver /benchmark)

mcp__lighthouse__get_core_web_vitals({ url: "<URL>" })
// Comparar com baseline guardado

Minuto 10-15 — Logs e Erros

# Erros PHP nas últimas 15 min
ssh server "tail -100 /var/log/php/error.log | grep '$(date -d '15 minutes ago' +%H:%M)'"

# Erros Nginx/Apache
ssh server "tail -50 /var/log/nginx/error.log"

# WooCommerce (se aplicável)
wp --path=/var/www/html wc log list 2>&1 | head -20

Output — Relatório Canary

## Canary Check — [Site] — [Data] [Hora]

**Deploy:** [O que foi alterado]

| Check | Estado | Detalhe |
|-------|--------|---------|
| HTTP 200 | ✅/❌ | |
| SSL | ✅/❌ | |
| Tempo resposta | ✅/❌ | Xs |
| Sem erros PHP | ✅/❌ | |
| Performance score | ✅/❌ | X% (base: Y%) |
| Logs limpos | ✅/❌ | |

**Resultado:** ✅ DEPLOY ESTÁVEL | ⚠️ INVESTIGAR | ❌ REVERTER

Critérios de Reversão Imediata

❌ HTTP response != 200 → REVERTER
❌ SSL falha → REVERTER  
❌ "Fatal error" em qualquer página → REVERTER
❌ Tempo resposta > 10s → INVESTIGAR
❌ Performance score caiu >15 pontos → INVESTIGAR
❌ Logs com erros críticos → INVESTIGAR

Escalada Automática

Se algum check falha:

1. NOTIFICAR: criar issue no Desk CRM com urgência P1
2. REVERTER: se erro crítico, reverter imediatamente
3. DOCUMENTAR: o que falhou e quando
4. ANALISAR: root cause antes de re-deploy

Healing Log

{"date":"","issue":"","fix":"","source":"user|auto"}

Skill /canary v1.0 | 06-04-2026 | Eixo 2B — gstack pattern