release-readiness-triage-mcp

Agrega falhas de CI e emite vereditos de release GO/NO_GO

GitHub

Documentação

🚦 release-readiness-triage-mcp

npm CI License: MIT

Pare de ler logs de CI. Comece a receber veredictos.

Servidor MCP que agrega falhas de testes, cruza o histórico de flakiness e gera uma decisão de release GO / CONDITIONAL_GO / NO_GO / INVESTIGATE — para que seu agente de IA possa fazer a triagem de uma execução de CI quebrada em segundos, em vez de pedir que você leia 3000 linhas de logs.

🤔 O problema

Em qualquer codebase real, o CI sempre tem algo falhando. A pergunta difícil não é "existem falhas?" — é "essas falhas são regressões reais, ou apenas o ruído habitual?"

Responder a isso exige correlacionar três sinais ao mesmo tempo:

  • 🔍 Assinaturas de erro — é a mesma falha repetida 12 vezes, ou 12 problemas diferentes?
  • 📊 Histórico de flakiness — esse teste é conhecido por ser instável?
  • 🔗 Mudanças de código — o teste que falha está realmente relacionado ao que mudou?

Um agente de IA não consegue fazer isso sem ferramentas estruturadas. Logs de CI brutos têm milhares de linhas. Bancos de dados de flakiness são externos. O mapeamento código→teste exige análise de AST. Sem este MCP, o agente apenas adivinha.

🛠️ Ferramentas

aggregate_suite_failures

Agrupa falhas por assinatura de erro normalizada, deduplica erros repetidos e categoriza como assertion / timeout / network / crash. Passe customInfraPatterns para erros específicos de nuvem.

cross_reference_flakiness

Pontua cada falha contra seu histórico de flakiness: KNOWN FLAKY, MILDLY FLAKY ou NO HISTORY.

correlate_code_changes

Corresponde arquivos alterados a testes que falham. Funciona de forma autônoma ou com listas de testes afetados pré-computadas do ast-impact-mapper-mcp.

generate_release_recommendation

A etapa final. Gera um veredicto ponderado por risco, com pontuação de confiança e detalhamento completo. Suporta format: "markdown" para comentários em PRs do GitHub e Slack.

Níveis de veredicto:

  • NO_GO — regressão em um domínio crítico (payment, auth, billing, checkout, security)
  • CONDITIONAL_GO — regressão em um domínio de risco baixo/médio (analytics, docs, admin); revise antes de liberar
  • GO — todas as falhas são conhecidas como flaky ou ruído de infraestrutura
  • INVESTIGATE — há incógnitas demais para decidir

A saída inclui:

  • aggregate_risk_score — 0,0–1,0, união de probabilidade em todas as contribuições de risco de regressão
  • failing_tests_analysis[] — detalhamento por regressão com domain, severity (HIGH/MEDIUM/LOW), risk_contribution, blast_radius

detect_temporal_failure_patterns

Analisa falhas históricas com timestamps para identificar artefatos cronométricos — falhas que só aparecem na mesma hora UTC, dia da semana, dia do mês, ou durante transições de horário de verão. Quando um padrão é encontrado, a falha é um artefato de tempo, não uma regressão de código.

A saída inclui:

  • temporal_pattern_detected — booleano
  • clusters[] — por teste: pattern_type (hourly | daily | monthly | timezone_shift), cluster_times, confidence_score

analyze_rollback_readiness

Escaneia um repositório em busca de arquivos de migração versionados (Flyway V*.sql, Prisma migration.sql, Liquibase XML/YAML) e classifica cada operação como aditiva (segura para rollback) ou destrutiva (somente correção para frente).

Operações destrutivas detectadas: DROP TABLE, DROP COLUMN, ALTER COLUMN TYPE, MODIFY COLUMN, TRUNCATE

A saída inclui:

  • rollback_eligible — booleano
  • blocking_migrations[] — cada um com file, line, operation, reason
  • deployment_strategy — standard | forward_fix_only

🧪 Como é na prática

5 falhas no CI. O que é real, o que é ruído?

failures:
  - Auth Suite > login with expired token   → "Expected status 200, got 401"
  - API Suite > health check                → "connect ECONNREFUSED 127.0.0.1:3000"
  - Button Suite > renders button correctly → "Expected null, got <button>Submit</button>"
  - Search Suite > debounce timing          → "Expected 42, received 43"
  - Storage Suite > upload avatar           → "GCP quota exceeded for this project"

changedFiles: ["src/components/Button.tsx"]
affectedTests: ["renders button correctly"]
customInfraPatterns: ["GCP quota exceeded"]
format: "markdown"

Saída:

## 🔴 Release Recommendation: NO_GO (75% confidence)

> 1 confirmed regression(s) in critical domain(s) [payment]. Do not release.

**Aggregate risk score:** 1.0

| Category            | Count |
| ------------------- | ----- |
| Total failures      | 5     |
| 🔴 Real regressions | 1     |
| 🟡 Known flaky      | 2     |
| ⚪ Infra blips      | 2     |
| ❓ Unknown          | 0     |

### Risk Breakdown

| Test                                   | Domain | Severity | Risk | Blast Radius |
| -------------------------------------- | ------ | -------- | ---- | ------------ |
| Button Suite::renders button correctly | core   | MEDIUM   | 0.5  | 1            |

### Blockers (must fix before release)

**Button Suite > renders button correctly**

- Test is directly affected by code changes in this commit
- `Expected null, got <button>Submit</button>`

### Safe to ignore

- ~~Auth Suite > login with expired token~~ — Historically flaky: 73% failure rate in history
- ~~API Suite > health check~~ — Error pattern matches infrastructure issues (network)
- ~~Search Suite > debounce timing~~ — Mildly flaky: 22% historical failure rate
- ~~Storage Suite > upload avatar~~ — Error pattern matches infrastructure issues (network)

Uma chamada de ferramenta. Um veredicto. Vá corrigir Button.tsx.

⚡ Configuração

{
  "mcpServers": {
    "release-readiness-triage": {
      "command": "npx",
      "args": ["-y", "release-readiness-triage-mcp"]
    }
  }
}

🚀 Uso

"Aqui estão as falhas da nossa execução de CI, nosso banco de dados de flakiness e os arquivos alterados neste PR. É seguro liberar?"

O agente chama generate_release_recommendation e retorna um veredicto com detalhamento completo — pronto para colar em um comentário de PR ou no Slack.

Funciona de forma autônoma, ou como meta-orquestrador sobre:

📦 Links

Licença

MIT