# Raciocinador de Caminho de Fluxo

> A habilidade sênior é recusar-se a fazer troubleshooting até o caminho estar entendido. Sete seleções constroem um mapa canônico de saltos com fluxos laterais, segmentos TLS, pontos de reescrita e domínios de falha ranqueados - e os desconhecidos permanecem visivelmente desconhecidos.

- Tool: https://ronutz.com/pt-BR/tools/flow-path-reasoner
- Family: Operações e fieldcraft

---

## O que a ferramenta faz

Descreva o caminho como você acredita que ele corre - arquétipo, resolução de nomes, intermediários, transformação de endereços, comportamento TLS, fluxo de autenticação e caminho de retorno, mais um preset de família de comandos - e um registro fixo de 27 regras originais constrói o modelo deterministicamente. O resultado é um MAPA DO CAMINHO EM CAMADAS: a cadeia de saltos em ordem canônica, renderizada como diagrama com marcadores de transformação e TLS em cada nó; os FLUXOS LATERAIS de resolução e identidade que correm fora do caminho primário; o mapa de segmentos TLS (cada terminação é uma história separada de certificado, SNI e cifra); os pontos de transformação onde endereços - e portanto a identidade nos logs - mudam de significado; pontos de evidência nomeando onde imposição e logging precisam ser estabelecidos; e, acima de tudo, DOMÍNIOS DE FALHA CANDIDATOS ranqueados, cada um com o que o SUSTENTARIA e o que o ENFRAQUECERIA. Seleções desconhecidas nunca são disfarçadas: aparecem como lista explícita de desconhecidos, como alertas de qualidade e como pontuação para o próprio domínio "caminho não estabelecido".

## O que ela deliberadamente não é

O mapa é um MODELO PROPOSTO montado a partir das suas seleções - nunca topologia descoberta. A regra base do motor dispara em toda execução e diz exatamente isso, e o checklist de verificação começa por confirmar cada salto com o seu dono. Quando dois ou mais middleboxes são modelados, a cadeia usa uma ordem canônica assumida e uma regra avisa. A ferramenta não faz chamadas de rede, não realiza descoberta, não afirma ordem de processamento de pacotes de nenhum fornecedor e não sugere caminhos de contorno de controles. Exportações descrevem topologia interna, então o alerta de sensibilidade de topologia também dispara em toda execução. Rótulos e notas em texto livre vão apenas para a exportação; nunca influenciam as regras.

## Como o modelo é construído - e como é verificado

A inserção de nós segue uma ordem canônica (cliente, borda SSE, firewall, balanceador, proxy, par de gateways VPN, servidor); transformações se prendem ao nó mais plausível por preferência fixa; segmentos TLS derivam do comportamento declarado contra os nós capazes de terminar TLS efetivamente modelados - e quando os dois discordam (terminação única declarada sem nó capaz), o modelo sinaliza a inconsistência em vez de inventar um terminador. Regras são predicados puros que contribuem pontos para domínios de falha candidatos; o ranking é por pontuação decrescente com a ordem de definição como desempate determinístico; o selo de sinal é uma faixa de pontuação (forte ≥ 60, moderado ≥ 30, fraco abaixo), nunca uma probabilidade.

A verificação segue o modelo de snapshot de disparo de regras do cluster com um pino específico do FPR: para cada entrada de teste, o build afirma exatamente quais regras disparam, a lista exata de domínios ranqueados, o conjunto exato de alertas e a SEQUÊNCIA DE SALTOS exata - a própria construção da cadeia é congelada. Treze vetores (nove cenários, quatro rejeições) fixam o registro atual; qualquer deriva quebra o build.

## Entrada da API

A entrada com paridade de API recebe um objeto JSON: `{"archetype", "resolution", "intermediaries", "transformation", "tls", "auth", "returnPath", "preset", "notes": {"nodeLabels", "title", "notes"}}`. Todos os campos exceto `notes` usam os vocabulários fechados do formulário; um valor fora do vocabulário é erro de formato, nunca um palpite.

## Standards and references

- Original path-reasoning ruleset (D-18: original by construction) - the 27-rule registry, 13 failure-domain candidates, canonical chain construction, TLS segmentation, side-flow modeling, scoring weights, signal bands, and quality warnings are original editorial work encoding standard path-reasoning practice (resolution as part of the path, separate return-path reasoning, identity side-flows, transformation boundaries); no external specification is claimed or reproduced

## Related reading

- [Mapeie o Caminho Antes de Fazer Troubleshooting](https://ronutz.com/pt-BR/learn/map-the-path-before-you-troubleshoot.md): As sessões de troubleshooting mais caras compartilham uma falha: ninguém sabia de fato o caminho. O hábito sênior é recusar-se a raciocinar sobre uma falha até a cadeia estar modelada - resolução incluída, retorno em separado, cada reescrita e fronteira TLS nomeada, e cada desconhecido visivelmente desconhecido.