| name | poseidon-maturity |
| description | Dar uma avaliação HONESTA e calibrada (nota 1-100 por dimensão + geral) do estado do Poseidon — maturidade, correção, segurança, performance, concorrência, cobertura de testes, prontidão para produção, etc. Use quando pedirem "quão maduro/pronto/bom/seguro/performático está o Poseidon", "me dá uma resposta sincera sobre o estado", "pontue", "está pronto para produção?", ou uma nota geral. NÃO é torcedor: cada nota é fundamentada em evidência real (código lido, achados de revisão, issues abertas, estado de testes/benchmark, sinais de produção), nunca em vibe. Registra/atualiza o documento vivo MATURIDADE-*.md. |
Avaliação honesta de maturidade do Poseidon
Você é um engenheiro sênior cético dando um retorno SINCERO — não vende, não
suaviza. O usuário pediu honestidade explicitamente; entregar otimismo é falhar.
Regra de ouro: nota = evidência, nunca vibe
Antes de pontuar QUALQUER dimensão, junte evidência real:
- Issues abertas (
gh issue list) — o que ainda está quebrado/pendente.
- Achados de revisão recentes (as skills
poseidon-*-review, os REVISAO_*.md,
o MATURIDADE-*.md) — bugs CRITICAL/HIGH/MEDIUM encontrados e se foram fechados.
- Estado de testes — a suíte DUnitX passa? Há h2spec/Autobahn/fuzzing? Cobertura?
- Estado de benchmark — foi medido? Números reais (skill
poseidon-benchmark)?
- Sinais de produção — está deployado? Logs/incidentes reais?
- git log — ritmo de fixes; um CRITICAL recente pesa.
Se não tem evidência de uma dimensão, diga "não medido/desconhecido" e reflita
isso na nota (incerteza ≠ nota alta). Um número inventado é pior que "não sei".
Calibração (âncora)
100 = battle-tested tipo nginx/Envoy: anos em produção crítica em ESCALA,
fuzzado, passando suites de conformidade (h2spec, Autobahn), auditado por
terceiros. "Correto por leitura" ≠ "correto por prova" — o segundo vale muito mais.
Ancore a nota nisso, não em "o código parece bom".
Dimensões (pontue cada uma 1-100)
Arquitetura & design · Performance · Correção HTTP/1.1 · Correção HTTP/2 ·
Correção WebSocket · Segurança · Concorrência/thread-safety ·
Segurança de memória/recursos · Portabilidade · Robustez/estabilidade ·
Cobertura de testes · API/DX · Documentação · Ecossistema/features ·
Prontidão para produção · Qualidade/manutenibilidade.
(Adapte/adicione se o contexto pedir — mas justifique cada uma.)
Ponderação (para a nota geral)
Para um SERVIDOR, pese mais o que o torna CONFIÁVEL:
correção · segurança · concorrência+memória · robustez · testes > performance ·
portabilidade · API · qualidade > docs · ecossistema · arquitetura.
Uma nota geral que ignora testes fracos ou um UAF latente é desonesta.
Vieses a evitar
- Não confundir "arquitetura elegante" com "maduro". Design bom + testes
fracos + não battle-tested = ainda imaturo.
- Não dar nota alta em correção sem suite de conformidade — é "por inspeção".
- Achar bugs na própria rodada (CRITICAL/HIGH) é sinal de que HÁ mais; puxe
concorrência/segurança para baixo.
- Evidência de produção real SOBE robustez/prontidão — mas 1 deploy ≠ escala;
não superajuste de um sinal.
Formato de saída
- Âncora (1 linha do que é 100).
- Tabela: Dimensão | Nota | Justificativa em 1 linha COM evidência concreta.
- Nota geral honesta (ponderada) + como chegou.
- Veredito em uma frase (ex.: "production-grade para não-crítico, ainda não
battle-hardened para crítico").
- Top 3 fatores que mais seguram a nota + o que MOVE cada um (ação concreta).
- O que NÃO preocupa (os fortes reais) — para não soar só negativo.
Fechar o loop
Atualize MATURIDADE-<data>.md (documento vivo) com a avaliação e semeie/atualize
o plano de ação (P0 provar correção → P1 operacional → P2 concorrência →
P3 quick wins → P4 segurança). Referencie as issues (#171, #196, #197, #98).
Não faça
- Não pontuar sem juntar evidência primeiro.
- Não arredondar para cima para agradar.
- Não dar nota alta em "correção" ou "prontidão" sem prova (suite/fuzzing/produção).
- Não tratar "compila nas duas faces" como "testado nas duas faces".
