5 ideas cover the whole tool. Each maps to something visible in the output or the .crux/ directory.

behavior target

The command you pass with -c. Exit 0 means the behavior holds. Anything else means it changed. Output gets captured so you can read it in replay & reports, but classification never parses text. That rule is why crux can blame any observable behavior, not just builds.

range

Ordinary git syntax such as HEAD~20..HEAD or v1.0.0..v1.1.0. The range bounds everything: search cost, suspect count, probe count. Start wide when you have no clue. Start tight when you know it broke this week.

flip commit

The oldest commit in the range where the behavior fails. Binary search finds it in ceil(log2(n)) runs: 11 probes on 1,000 commits, 7 on 100. The search assumes 1 flip that sticks.

animation of the binary search narrowing a 200 commit history onto the flip commit in 8 probes

essential diff

The smallest set of hunks from the flip commit that still reproduces the failure on the parent commit alone. Every reduction is verified by running your command. It's the difference between "this commit touched 400 lines" and "this line broke it".

guardian

A named behavior with an expected state, declared once, stored in .crux/guardians.json, committed with the repo. Watch mode checks all of them.

signatures

Every observation records 2 hashes. The code signature is sha256 over the HEAD tree, so it moves exactly when committed content moves. The environment signature is sha256 over OS, architecture & tool versions. Comparing them classifies a change as code or environment before any search runs, which stops you from blaming a commit for what a toolchain update did.

edit this page