Every line in a who result means one specific thing. Read them in order and the report turns from noise into a story.

the cmd line

A sha256 fingerprint of your target command. Same command, same fingerprint, every time. That's how crux ties observations together across runs in the history log.

the commit line

The answer. The first commit in the range where the behavior fails, verified the same way bisect verifies its result. Two differences: it's automatic, and it checks your behavior, not a build.

the suspects line

Every file touched by any commit in the range, not just the flip commit. It's deliberately coarse: blast radius, not cause. Short list, read it as context. Long list, skip to the essential lines.

the essential block

Bisect stops at the commit. crux split the flip commit's diff into pieces at hunk boundaries & asked one question per candidate subset: applied alone onto the parent, does the behavior still break? Passing subsets get discarded. What survives is the smallest set that keeps the failure alive. In the example, 3 hunks reduced to 1: the field assembly order was the whole story. The count in parentheses is the probe cost.

the upstream line

Touch a vendored dependency in the flip commit and an extra line appears:

dependency: libc [vendored-crate] 0.1.0 -> 0.2.0 (vendor/libc/Cargo.toml)
  upstream: https://github.com/example/libc

crux read the dependency's manifest at both the parent & the flip commit and reported what moved. That's evidence, not a guess. With --upstream-deep it resolves the version tags on the declared repository and lists upstream commits between them. Missing tags or no network, and it prints that attribution was unavailable. It doesn't invent a culprit.