Engineering Postmortem Operator vs Test Plan Operator
Diferença principal: Engineering Postmortem Operator é um componente skill voltado a Estruturar postmortem técnico orientado a sistema., enquanto Test Plan Operator é um componente skill voltado a Criar estratégia de testes proporcional ao risco da mudança.. A melhor escolha depende do objetivo, da compatibilidade necessária e da menor exposição operacional suficiente.
Comparação objetiva
| Componente | Tipo | Autonomia | Compatibilidade | Trust state | Permissões | aprovação humana |
|---|---|---|---|---|---|---|
| Engineering Postmortem Operator | skill | manual | Claude Code | not-tested | nenhuma declarada | sim, proteção declarado |
| Test Plan Operator | skill | manual | Claude Code | not-tested | nenhuma declarada | sim, proteção declarado |
Quando usar Engineering Postmortem Operator
Use Engineering Postmortem Operator quando o trabalho central for Estruturar postmortem técnico orientado a sistema.. O comando canônico é /plugin install atlas-engineering-postmortem-skill@reveno. Antes de instalar, confirme a compatibilidade declarada (Claude Code) e limite o acesso ao menor conjunto necessário.
Quando usar Test Plan Operator
Use Test Plan Operator quando o objetivo estiver mais próximo de Criar estratégia de testes proporcional ao risco da mudança.. O comando canônico é /plugin install atlas-engineering-test-plan-skill@reveno. Se os dois componentes cobrirem partes diferentes do fluxo, monte uma stack e revise overlaps antes de instalar ambos.
Riscos e controles de Engineering Postmortem Operator
Skill de instrução, sem shell, rede, credenciais ou execução automática. Risco principal: usar uma saída não revisada ou fornecer contexto insuficiente. Não culpar pessoas nem reduzir incidente complexo a causa única. Permissões declaradas: nenhuma declarada. Aprovação humana: Revisão humana obrigatória antes de enviar, publicar, aprovar ou executar a saída em ambiente real..
Riscos e controles de Test Plan Operator
Skill de instrução, sem shell, rede, credenciais ou execução automática. Risco principal: usar uma saída não revisada ou fornecer contexto insuficiente. Não confundir quantidade de testes com cobertura do risco relevante. Permissões declaradas: nenhuma declarada. Aprovação humana: Revisão humana obrigatória antes de enviar, publicar, aprovar ou executar a saída em ambiente real..
Trust Score e estado de confiança
Engineering Postmortem Operator: not-tested: evidência insuficiente; não é reprovação e não entra como zero na nota.
Test Plan Operator: not-tested: evidência insuficiente; não é reprovação e não entra como zero na nota.
Estados not-tested são excluídos da nota e nunca tratados como zero. Medium ou high risk pedem contexto e revisão; não significam automaticamente “não use”.
Como decidir e combinar
Escolha primeiro o tarefa específico. Depois compare origem, manutenção, autonomia, compatibilidade, rede, shell, arquivos, credenciais e ações externas. Prefira a menor autonomia e o menor conjunto de permissões que resolvam o caso. Se a decisão exigir os dois componentes, gere uma stack com arquivo de versões, CLAUDE.md e política inicial.
Montar stack com estes componentes · Analisar outra origem · Entender Trust Score
Perguntas frequentes
Qual componente é mais seguro?
Os metadados não permitem declarar segurança absoluta. Compare os sinais observados e teste no seu contexto.
Posso instalar os dois?
Sim, quando as capacidades forem complementares. Revise comandos duplicados, dependências, permissões combinadas e pontos de aprovação humana.
Quando preciso de governança?
Quando a composição toca dados reais, múltiplas áreas, credenciais, decisões operacionais ou produção. Nesse ponto, avalie Governança e Harness.
Plano de teste comparativo
Teste cada opção separadamente com a mesma entrada, o mesmo critério de qualidade e o menor acesso possível. Registre versão, tempo, resultado, erro e necessidade de retrabalho. Depois teste a composição somente se as capacidades forem complementares. Não conecte credenciais reais durante a primeira rodada. Se uma opção exigir rede, shell, arquivos ou ação externa, documente destino, reversibilidade e responsável pela aprovação antes de decidir.