Selectivity Makes Large Bug Reports Easier to Understand

A minimal reproducer is a small example that still demonstrates a problem. It gives the person investigating a bug less material to read and fewer irrelevant details to carry through each experiment. Getting there is often laborious. You remove a group of rows, rerun the program, discover that the failure has vanished, restore the rows and try a smaller group. It is useful work, just rather repetitive.

Selectivity turns that routine into a search driven by a predicate. The predicate is a command that answers whether the particular behavior survives in the candidate input. Selectivity begins with larger deletions and works toward smaller ones when necessary. Each successful deletion becomes the new starting point. Eventually the engine reaches individual units, such as one line or one file, and checks whether removing any of them still preserves the predicate.

The important choice happens before the search: deciding what the predicate actually means. If the original program crashes, checking for any nonzero exit is usually too loose. A malformed candidate might fail for an entirely different reason. A good wrapper checks validity and recognizes the expected failure signature. The reducer can follow that definition faithfully; it cannot repair a definition that quietly changes the question.

Directory input adds another level. Removing a whole file can expose the few relevant documents in a large bundle. Reducing lines inside the remaining files can then expose the settings or records that matter. Selectivity repeats those passes until a full loop leaves the modeled input unchanged. It preserves directory structure, including empty directories, because this release treats files and lines as reduction units rather than attempting every possible filesystem transformation.

The result needs a precise description. Locally minimal means that no single remaining selected unit could be deleted while satisfying the predicate under the checks that were run. It does not rule out a smaller result reachable through a different combination of edits. Nor can three successful observations prove that a flaky program will behave the same way tomorrow. Selectivity keeps those limits visible in the report, which is where they belong. The reference explains the status fields and the conditions that prevent a minimality claim.