Critical Review — 2026-07-04¶

Revisão crítica independente do projeto inteiro (estratégia, código, execução), conduzida por agente (Claude Fable 5) a pedido do mantenedor. Consolidada aqui para que o racional sobreviva à sessão. Plano de execução aprovado pelo mantenedor em 2026-07-04. Segue o padrão da avaliação multi-especialista de 2026-06-16 (ver ROADMAP decision log).

Veredito em uma frase¶

O projeto é intelectualmente maduro e operacionalmente adolescente: o caminho para "topo de linha" não passa por adicionar inteligência, autonomia ou specs — passa por executar as duas medições que o próprio projeto definiu como bloqueantes (P0.1, P0.2), queimar a dívida mecânica (PH.x) em paralelo, e deixar os números decidirem se o produto é a originação causal, o eval harness, ou um conjunto de recording rules bem feitas.

O risco nº 1: planejamento correu 3 fases à frente da execução¶

Gates P0.1 (synthetic injection) e P0.2 (competitive teardown) decidem se existe um produto. Specs prontas desde 2026-06-14; não executadas até 2026-07-04.
No mesmo período: 24 commits — quase todos docs e CI.
Pedir "mais features/specs/ML" neste estado é o modo de falha que o próprio decisions.md (Decision 8) documenta: "Swapping the engine without measurement is re-shipping a detector you can't evaluate."

O que está excepcional¶

Autocrítica institucionalizada: Decision 8 com critérios de kill explícitos (hypothesis-causal-origination.md) é maturidade rara em AIOps. O evaluation-scorecard.md é publicável.
Replay mode funcional, zero side effects, smoke-testado contra endpoints reais.
Disciplina de cardinalidade, org-neutralidade, 12-factor, dry-run por default.
Cobertura Go 35% → 89.4% em um sprint.
Specs em formato executável por agente (tasks com dependências).

Achados críticos (com evidência)¶

1. O serviço de ML é decorativo — e risco negativo¶

ml/server/multivariate.py (serviço Python inteiro: 271 linhas, 0 testes):

O Isolation Forest treina apenas sobre vetores já anômalos (só é invocado com ≥2 anomalias correlacionadas). Ele aprende "como é uma anomalia típica" e sinaliza anomalias atípicas — e com isso escala severidade warning→critical.
_history cresce sem limite (vazamento de memória); modelo não persiste — a cada restart precisa de 50 alertas correlacionados antes de opinar.

Decisão aprovada (→ ADR-0010): congelar a escalada de severidade via ML até o gate P0.1 produzir números; manter anotações ml_score/ml_contributors para coleta de dados. Se mantido depois: treinar sobre vetores saudáveis, persistir modelo, limitar histórico.

2. Zero ground truth, estruturalmente¶

Nunca saiu do dry-run, nunca deployou, feedback loop (P3.3) não existe. Pelo próprio scorecard do projeto, o sistema tira 0 no eixo 3 (Ground Truth) — o eixo que o scorecard chama de decisivo. Precision/recall desconhecidos após ~5 semanas de sistema "funcional".

3. Dívida de CI enumerada mas não queimada¶

Gates todos report-only; CVE crítico grpc-go (CVE-2026-33186) pendente; gofmt em 16 arquivos; decisão de branch model em aberto (resolvida nesta revisão: trunk-based → ADR-0009 — o histórico do repo já é trunk).

4. Riscos estruturais¶

Dependência de repo pessoal (karlipegomes/staffops-otel-libs — PH.13); bus factor 1.

5. Fricção para execução por agentes¶

.claude/ quase vazio; comandos de build/test como prosa multi-linha no AGENTS.md; sem verify de um comando; sem ponto de entrada para sessão fria. Diagnóstico completo e plano de 28 tasks: specs/agent-native-execution/.

Plano aprovado (ordem de execução)¶

Trilho A — decide o produto:

specs/agent-native-execution/ — destrava execução por agentes (pré-passo, curto)
Executar P0.1 (specs/synthetic-injection/, 29 tasks) → recall lower-bound + FP upper-bound reais
Executar P0.2 (specs/competitive-teardown/, time-boxed) → decide produto-ou-config. Qualquer resultado é vitória; não rodar é a única derrota.
Só depois: P0.3 (validar degradation model) e a decisão do seam.

Trilho B — mecânico, paralelo, sem conflito com A:

P0.4 (FDR/Benjamini-Hochberg) — barato, ataca ~1000 FP/dia, vale em qualquer cenário
PH.10 (testes ML: 271 LOC → 90% é 1-2 dias) e PH.9 (fechar readiness/ml/leader)
P2.9 (anti-poisoning) e P2.8 (baseline por workload) — os dois bugs mais graves do baseline
Bump grpc (CVE crítico), gofmt, PH.15 (Helm) → destrava PH.1/PH.2/PH.4

Depois: P5.2 deploy dev (dry-run) → 1-2 semanas shadow → P5.3 tirar dry-run em escopo pequeno junto com P3.3 (feedback loop). Sem feedback, sair do dry-run é gerar ruído sem aprender.

Posição sobre ADR e PRD¶

docs/architecture/decisions.md já é um ADR log de qualidade; formalizar em docs/adr/000N-*.md é cosmético (tasks B1-B3 do agent-native spec). ADRs novos honestos hoje: 0009 trunk-based, 0010 ML freeze. O ADR da hipótese causal só existe após os gates.
PRD agora seria ficção — o PRD é o output do gate P0.2, não o input. Único PRD escrevível após P0.1: eval harness como produto (ver abaixo).

Sugestões de mercado (sequenciadas, não imediatas)¶

O ativo mais diferenciado talvez já exista: o eval harness (replay + injeção sintética + FDR). "CI para configuração de alertas" — regressão de detecção antes de qualquer mudança chegar ao cluster — é algo que Datadog/Robusta/Keep não entregam bem, e sobrevive aos dois resultados do gate P0.2. Candidato a PRD após P0.1.
AI SRE é a direção do mercado e a spec certa já existe (P5.5, specs/agent-api-integration/): cadeias causais estruturadas são o input ideal para agente de investigação. Manter sequência: só após alertas reais (P5.3).
Estatística moderna no lugar de mais ML: FDR (P0.4) e depois conformal prediction para thresholds adaptativos com garantia de FP rate — substitui o z>3 fixo sem cair no atrator "multivariado sobre 400 séries" que a própria hipótese chama de armadilha.
Não fazer: os anti-goals do ROADMAP estão certos (sem streaming pipeline, sem UI, sem federação, sem mais detectores). Adição desta revisão: nenhuma spec de produto nova até P0.1/P0.2 rodarem.

Rodada 2 — onde o produto ainda peca mesmo executando todo o plano acima¶

Adicionada no mesmo dia, a pedido do mantenedor: assumindo P0.1/P0.2 executados, PH.x queimados e deploy feito — o que ainda falta para detecção inteligente e assertiva sem IA (integração aigent-squad opcional por cima)?

Verificado no código (não especulação):

Decisão em sample único — detection/adaptive.go: Z>3 num único ciclo dispara; Z>5 vira critical. Sem persistência N-de-M, sem histerese. Spike de 60s = alerta.
Estatística não-robusta — mean/stddev (EWMA/Welford): o outlier de agora contamina o baseline que julga o próximo sample. Median/MAD resolve e mitiga poisoning (P2.9) de graça.
Cegueira semântica — nenhum sinal declara direção da maldade (up_bad/ down_bad), classe (RED/USE), teto, papel (leading/lagging). O detector trata "latência caiu" como "erro subiu". A semântica existe só na cabeça de quem escreveu a regra.
Cegueira a mudanças planejadas — eventos K8s são ingeridos (ingestion/events.go) mas não existe janela de supressão pós-rollout. Todo deploy gera anomalias esperadas de CPU/restart/latência → a maior fonte individual de FP em Kubernetes.
Cegueira a rampas segue sem correção planejada — Decision 8.4 documenta (EWMA persegue a subida), mas nenhum item do roadmap ataca (CUSUM/Page-Hinkley são a resposta clássica, O(1) por série).
Sem ciclo de vida de regra — regra entra no config.yaml e vive para sempre; não há orçamento de FP por regra, critério de demote, nem revisão.

Resposta consolidada: metodologia + template completo em docs/detection/methodology.md — catálogo de sinais (schema YAML), árvore de decisão de detector, menu de 7 técnicas não-IA priorizadas por valor/custo (com marcação do que é detector-core e portanto gated por P0.1), métricas de qualidade por regra e globais, ciclo de vida de regra, e modelo de custo em 3 tiers. Itens novos no ROADMAP: Phase 1.5.

Rastreabilidade¶

Artefato	Onde
Diagnóstico de tooling + 28 tasks	`specs/agent-native-execution/` (requirements + tasks)
Este report	`docs/review-2026-07-04.md`
Entrada no decision log	`ROADMAP.md` § Decision log, 2026-07-04
ADRs a criar	0009 (trunk-based), 0010 (ML freeze) — tasks B2/B3