# Construtor de Pacote de Escalação para TAC > Descreva o problema que você está prestes a escalar; um conjunto fixo de regras monta um pacote completo de suporte do fornecedor e uma lista dos artefatos que ainda faltam coletar antes de abrir o chamado, removendo o que você já tem. Estrutura a passagem; não abre um chamado nem contata nenhum fornecedor. - Tool: https://ronutz.com/pt-BR/tools/tac-escalation-packet-builder - Family: Operações e fieldcraft --- ## 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. ## Standards and references - Original TAC-escalation ruleset (D-18: original by construction) - the 12-rule registry, 11 to-collect diagnostic artifacts with vendor-flavored command hints, the collected-satisfies mapping, 8 fixed packet sections, 5 readiness notes, and the readiness derivation are original editorial work encoding standard vendor-support hand-off practice (problem statement, exact error, timeline, environment, diagnostics, reproduction, impact, the ask); the diagnostic artifact names are generic operational captures and no vendor procedure or specification is reproduced ## Related reading - [Chamados de TAC Que São Triados Rápido](https://ronutz.com/pt-BR/learn/tac-cases-that-get-triaged-fast.md): Os chamados de suporte mais lentos raramente são os problemas mais difíceis; são os que foram abertos sem o diagnóstico que o fornecedor precisa. Um chamado que chega completo — problema claro, erro exato, o pacote de diagnóstico, o impacto — pula as idas e vindas e começa com um engenheiro de fato trabalhando nele.