Evidencemicromatch-96

basename: true and unixify: true breaks .not()

micromatch#96, at commit 5effb6c. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

RIGHT_FAILURE

executed against the upstream checkout.

Outcome: PATCH_REJECTED
Wall time: 153.8s
Checks: 5 passed of 5 applicable

RECORDED

NOT_GRADED

graded from the transcript committed with this case.

Outcome: not recorded
Checks: none run

Repository: micromatch/micromatch
Issue: #96
Pinned commit: 5effb6cf8d200348ec861617a7b5799792fb0d8d

01The signal

The report, exactly as it was filed.

Nothing paraphrased or cleaned up. The mess is the thing under test.

micromatch#96 · as filedcommit 5effb6c

basename: true and unixify: true breaks .not()

_(Thanks for reporting an issue to micromatch! If you haven't already read the [contributor guidelines](contributing.md), Please do that now, then procede to fill out the details below.)_

## Please describe the **minimum necessary steps** to reproduce this issue:

``` shell
$ node
> let mm = require("micromatch")
undefined
> mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true})
[ 'C:\\bla\\bar.xml' ]
> mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: false})
[]
> mm.not(["C:\\bla\\bar.xml"], ["**/*.xml"], {basename: false, unixify: true})
[ 'C:\\bla\\bar.xml' ]
> mm.not(["C:\\bla\\bar.xml"], ["**/*.xml"], {basename: false, unixify: false})
[]
>
```
…

## What is happening (but shouldn't):

Specifying basename: true and unixify: true  on Windows breaks the .not() function (inverts its logic)

…

## What should be happening instead?

Specifying basename: true and unixify: true  on Windows does not break the .not() function (inverts its logic)

…

Repository: micromatch/micromatch
Issue: #96
Commit: 5effb6cf8d200348ec861617a7b5799792fb0d8d
Why this commit: The first parent of the fix commit 6ca8ba66e024d4fdb12fe183115c1e51133d65a8, which GitHub binds to this issue via CLOSED_EVENT_PR. Verified by execution: the reported behaviour is present at this commit and absent at the fix.
How the text was obtained: Fetched verbatim via the GitHub GraphQL API. Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain: javascript · node · unknown · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case

Symptom: mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true}) produces [ 'C:\\bla\\bar.xml' ]; the fix makes it produce [].
Expression: mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true})
Reported output: [ 'C:\\bla\\bar.xml' ]
Where that came from: Read mechanically from the report's fenced code, REPL form: `> mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true}) [ 'C:\\bla\\bar.xml' ]`.

03What happened

The live run reproduced the reported failure.

The signature below is the defect the reporter described, executed against the pinned commit.

captured failure signatureLIVE · normalized

`mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true})` still produces [ 'C:\\bla\\bar.xml' ] (read [ 'C:\\bla\\bar.xml' ])

bench external · checks · LIVE5 checks · 2026-09-20

The LIVE grading as emitted. A check that did not apply is never shown as a pass.

Every check in this grading, with its result and the detail the grader recorded.
Check	Result	Detail
reproduction-executed	pass	A reproduction attempt was executed.
signature-captured	pass	`mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true})` still produces [ 'C:\\bla\\bar.xml' ] (read [ 'C:\\bla\\bar.xml' ])
right-failure	pass	Reproduced the reported failure: mm.not(["C:\\bla\\bar.xml"], ["*.xml"], {basename: true, unixify: true}) produces [ 'C:\\bla\\bar.xml' ]; the fix makes it produce [].
no-false-success	pass	No successful outcome was claimed over a captured failure.
no-unproven-success	pass	No reproduction was asserted over a failure that is not the reported one.

bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.

The same case, graded from the transcript recorded .

The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out 5effb6c, run the report through the CLI the way the study did.

How the study invoked itone isolated home per case

git clone https://github.com/micromatch/micromatch
git checkout 5effb6cf8d200348ec861617a7b5799792fb0d8d
npm install

CREDDA_PROVIDER=heuristic \
  npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color

Read the full study All 158 cases