O que faz
Descreva uma mudança planejada por meio de seis campos estruturados — tipo de mudança, ambiente, raio de impacto, reversibilidade, a janela e as salvaguardas já em vigor — e um registro fixo de 22 regras originais dispara de forma determinística sobre essa descrição. O resultado é um RUNBOOK ORDENADO montado em seis fases fixas: pré-voo, aprovações e comunicação, execução, verificação, gatilhos de rollback e retorno, e encerramento. Ao lado dele, a ferramenta expõe os riscos que o plano carrega (classificados por severidade: uma mudança sem volta, um raio de impacto amplo, uma janela em horário comercial num sistema crítico) e ressalvas de prontidão sobre a própria entrada — nenhum backup marcado como feito, um rollback não marcado como testado, o monitoramento não pronto. Cinco presets de domínio (genérico, load-balancer, dns, tls-pki, firewall) dão sabor às sugestões de comando onde algum se aplica. Um clique exporta um runbook em Markdown pronto para o chamado de mudança ou para a ponte, com os passos que você marcou já assinalados.
O que deliberadamente não é
Esta ferramenta estrutura e sequencia; ela nunca aprova uma mudança e nunca executa nada. Não faz conexões de rede, não pede credenciais nem segredos, e não substitui o processo de aprovação de mudança nem a revisão de produção. O runbook que ela monta é uma proposta para revisar e adaptar ao seu próprio ambiente e aos seus padrões — quem executa e assina é uma pessoa. As notas em texto livre (resumo, detalhe da mudança, responsável pelo retorno) fluem apenas para o runbook exportado; nunca influenciam quais regras disparam, de modo que o comportamento do motor permanece totalmente determinístico.
Como o runbook é montado — e como é verificado
Cada regra é um predicado puro sobre a entrada estruturada; ao disparar, ela puxa um conjunto de passos (cada um pertencente a uma fase fixa) e, opcionalmente, um fator de risco. Um passo referenciado por várias regras ainda aparece uma única vez, ordenado pela primeira regra que o puxou; as fases em si são sempre emitidas na mesma ordem operacional, então o runbook se lê de cima a baixo como um de verdade. Toda mudança recebe uma espinha de base (delimite o escopo, faça o baseline, confirme a aprovação, aplique, verifique contra o baseline, observe, defina um gatilho de rollback, encerre), e as especificidades se somam a partir do tipo de mudança, da reversibilidade, do ambiente, do raio de impacto, da janela e do preset. O painel "Por que estes passos?" lista cada regra que disparou com o seu motivo, de modo que o plano é auditável, não oracular.
Como não existe um único runbook "correto" para uma ferramenta consultiva, os vetores de ouro clássicos não se aplicam. O modelo de verificação — a decisão firmada pelo piloto do Construtor de Hipóteses de Falha para toda a família de Operações e Trabalho de Campo — é o de VETORES-INSTANTÂNEO DE DISPARO DE REGRAS: para cada entrada de teste, o build afirma exatamente quais regras disparam, na ordem do registro, os ids de passo exatos e ordenados em cada fase, o conjunto exato de fatores de risco e o conjunto exato de avisos de prontidão. Treze vetores (oito cenários, cinco rejeições) fixam o registro atual; qualquer desvio em regras, passos, atribuição de fase, riscos ou avisos quebra o build.
Entrada da API
O ponto de entrada com paridade de API recebe um objeto JSON: {"changeType", "environment", "blastRadius", "reversibility", "window", "safeguards": [], "preset", "notes": {"summary", "changeDetail", "backoutOwner"}}. Todos os campos exceto notes usam os vocabulários fechados mostrados no formulário; um valor fora do vocabulário (incluindo uma salvaguarda desconhecida) é um erro de formato, nunca um palpite. safeguards pode ser um array vazio.