Evidenceyaml-638

Negative zero treated inconsistently by `stringify` and `parse`

yaml#638, at commit 03709ca. 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: 135.2s
Checks: 5 passed of 5 applicable

RECORDED

WRONG_FAILURE

graded from the transcript committed with this case.

Outcome: INCONCLUSIVE
Wall time: 16.8s
Checks: 4 passed of 5 applicable

Repository: eemeli/yaml
Issue: #638
Pinned commit: 03709ca8fc83b70158f33a65637c8fb1651a6163

01The signal

The report, exactly as it was filed.

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

yaml#638 · as filedcommit 03709ca

Negative zero treated inconsistently by `stringify` and `parse`

**Describe the bug**
Negative zero is preserved by `parse` but not preserved by `stringify`

**To Reproduce**
```
> YAML.parse('-0')
-0
> YAML.parse('+0')
0
> YAML.stringify(-0)
'0\n'
> YAML.stringify(+0)
'0\n'
```

**Expected behaviour**
I expect both method to either drop zero sign or to preserve it, or to have an option for this. I prefer `preserve` to keep `parse(stringify(x)) == x`.
```
> YAML.parse('-0')
-0
> YAML.parse('+0')
0
> YAML.stringify(-0)
'-0\n'
> YAML.stringify(+0)
'0\n'
```

**Versions (please complete the following information):**

- Environment: node v24.6.0
- `yaml`: 2.8.1

**Additional context**
🤷🏻

Repository: eemeli/yaml
Issue: #638
Commit: 03709ca8fc83b70158f33a65637c8fb1651a6163
Why this commit: The fix commit's parent where the closing commit was identifiable in the repository, otherwise the commit that was HEAD of the default branch at the moment the issue was filed.
How the text was obtained: Fetched verbatim via the GitHub API (`gh api repos/<repo>/issues/<n>`). Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain: javascript · node · jest · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case

Symptom: YAML.stringify(-0) returns '0\n' while YAML.parse('-0') returns -0.
Expression: YAML.stringify(-0)
Reported output: '0\n'
Where that came from: The "To Reproduce" REPL block: `> YAML.stringify(-0)` and the `'0\n'` below it. Three of the four pairs in that block are repeated unchanged under "Expected behaviour"; this is the only one the report objects to.

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

`YAML.stringify(-0)` still produces '0\n' (read 0
)

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	`YAML.stringify(-0)` still produces '0\n' (read 0 )
right-failure	pass	Reproduced the reported failure: YAML.stringify(-0) returns '0\n' while YAML.parse('-0') returns -0.
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.

bench external · checks · RECORDED5 checks

The RECORDED 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	ENOENT at tests/yaml-test-suite.ts:49
right-failure	fail	Expected `YAML.stringify(-0)` still producing '0\n'.
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.

captured failure signatureRECORDED · normalized

ENOENT at tests/yaml-test-suite.ts:49

Fell back to running the existing test suite, which failed at tests/yaml-test-suite.ts:49 — a pre-existing, unrelated fixture/toolchain failure in the checkout (also emitting a stale caniuse-lite warning).

Provider heuristic, sandbox local. bench/external/README.md, the Results table and "The top three failure modes". Run 2026-08-21. Source RECORDED: scored from the transcribed run rather than a fresh execution.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out 03709ca, 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/eemeli/yaml
git checkout 03709ca8fc83b70158f33a65637c8fb1651a6163
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