Module diagnose 

Deterministic rules engine.

diagnose is a pure function over (name, &[Evidence]). There is no clock, no env, no fs, and no randomness — which is what makes the insta snapshot tests reproducible on any machine.

How a rule works

Each rule is a private function rule_*(name, evidence, reproduction) -> Option<Diagnosis>. The rule:

1. Inspects evidence for the variants it cares about. If the trigger pattern is absent, the rule returns None and the dispatcher tries the next rule.
2. If the trigger pattern is present, the rule calls [pick] to choose which evidence items to surface in the rendered output (and in what order).
3. The rule looks up its prose in prose.toml via prose, then constructs and returns a Diagnosis.

Why rule order matters

Rules are tried in order from most specific (network-layer failure) to least specific (application-layer failure). The dispatcher returns the first match. This matters for inputs where multiple rules could in principle fire — see the test tls_failure_rule_orders_after_dns_failure for the canonical example.

Why prose lives outside this file

The hand-written English content (likely-cause templates, hypotheses, unknowns, next-steps, escalation notes, severity rationales) lives in prose.toml at the crate root. Editorial changes (a clearer hypothesis, a tighter escalation note) do not require a code change. Logic changes (severity, rule order, evidence patterns) still go here.

Structs

Diagnosis

The output of diagnose, consumed by every renderer.

Enums

Severity

Severity rank assigned to a diagnosis. See SeveritySource for how a rule arrived at the rank, and the README’s “What it does (and does not) claim” section for the ranking philosophy (immediacy of failure, not blast radius).

SeveritySource

How the rule arrived at its severity rank.

Functions

diagnose

Diagnose a case by name and the evidence collected for it.