O que faz
Descreva o problema que você está prestes a escalar para o suporte do fornecedor — o domínio do produto, a severidade como o fornecedor a classificaria, se é reproduzível, o que você já coletou e o que já tentou — e um registro fixo de doze regras originais monta um pacote de escalação completo. O pacote tem oito seções fixas: a declaração do problema, severidade e impacto ao negócio, ambiente, linha do tempo, o que foi tentado, o que está anexado, o que ainda falta coletar e o pedido. A parte mais útil é a penúltima seção: uma lista de verificação dos artefatos de diagnóstico que você deveria reunir antes de abrir o chamado, porque a maior causa isolada de um chamado de suporte lento é um primeiro contato sem o diagnóstico que o fornecedor vai pedir de qualquer forma. Qualquer coisa que você já tenha coletado sai da lista e passa para os anexos. Alguns itens trazem uma sugestão em nível de comando com sabor do domínio do produto. Uma leitura de prontidão aproximada — pronto, quase ou reunir primeiro — informa quão completo está o pacote. Um clique exporta o pacote em Markdown para o chamado.
O que deliberadamente não é
Esta ferramenta não abre um chamado, não contata nenhum fornecedor e não coleta diagnósticos dos seus sistemas — ela diz quais anexar; quem coleta é você. Ela não diagnostica o problema; estrutura a passagem para que um engenheiro de suporte comece rápido. Não faz conexões de rede e não pede credenciais nem segredos. Os nomes de domínio de produto são usados apenas para indicar qual diagnóstico se aplica, e nenhum domínio implica qualquer autorização de treinamento ou de parceria de suporte. As notas em texto livre (resumo do problema, ambiente, referência do chamado) fluem para o pacote exportado, onde é o lugar delas, mas nunca influenciam quais regras disparam.
Como o pacote é montado — e como é verificado
Cada regra é um predicado puro sobre a entrada estruturada; ao disparar, ela adiciona itens a coletar e, opcionalmente, uma nota de prontidão. Todo chamado recebe os artefatos essenciais — uma declaração do problema, o erro exato, uma linha do tempo, o impacto ao negócio, as versões exatas, o pacote de diagnóstico do fornecedor e a configuração — e as especificidades se somam a partir da severidade (um chamado de alta severidade acrescenta um esboço de topologia e uma captura), da reprodutibilidade (reproduzível acrescenta passos exatos de reprodução; intermitente prepara uma captura para pegar a próxima ocorrência) e do domínio do produto (um caso TLS acrescenta uma captura do handshake; um caso DNS acrescenta os logs de consulta). Qualquer coisa já marcada como coletada é removida da lista. A leitura de prontidão aproximada é derivada da nota de prontidão de maior severidade. O painel "Por que esta lista?" lista cada regra que disparou com o seu motivo, de modo que o pacote é auditável, não oracular.
Como não existe um único pacote "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, a ordem fixa exata das seções, a lista a coletar exata com os artefatos já coletados removidos, as notas de prontidão exatas, as ressalvas exatas e a leitura de prontidão aproximada. Doze vetores (seis cenários, seis rejeições) fixam o registro atual; qualquer desvio quebra o build.
Entrada da API
O ponto de entrada com paridade de API recebe um objeto JSON: {"vendor", "severity", "reproducibility", "collected": [], "tried": [], "notes": {"problemSummary", "environment", "caseReference"}}. O fornecedor, a severidade e a reprodutibilidade usam os vocabulários fechados mostrados no formulário; collected e tried são arrays extraídos dos seus próprios vocabulários fechados. Um valor fora do vocabulário é um erro de formato, nunca um palpite; os arrays podem estar vazios.