bisectlisted

# Bisect: find the cause by binary search Every "it broke and I don't know why" problem has the same shape: a **space** of candidates, and a **predicate** that says whether any given candidate exhibits the bug. Finding the cause is then a search — logarithmic, not linear. This reframe matters because the search is the easy part. Two things decide whether the answer is correct: 1. **Choosing the right axis** to search along. 2. **Writing a predicate that is fast and deterministic.** Get those right and the answer falls out mechanically. Get the predicate wrong and the search returns a confident, wrong answer — silently. ## The one convention Every predicate in this skill uses the same polarity as `git bisect run`: ``` exit 0 -> bug ABSENT ("good") exit non-zero -> bug PRESENT ("bad") ``` A raw failing test command already obeys this, so it can usually be passed through unchanged. To invert a command that has the opposite polarity, prefix it with `!` — for example `! grep -q ERROR build.log`. ## Step 1: pick the axis Ask what changed between working and broken. Search along that dimension: | What changed | Axis | Tool | | --- | --- | --- | | Time — worked at an older commit | commits | `git bisect run` | | A specific input triggers it | the input file | `scripts/ddmin.py` | | A config/flag change | config lines | `scripts/ddmin.py --in-place` | | A `npm install` / `uv lock` | dependency versions | pin and bisect, see recipes | | Only on CI, not locally | en