Evidencecamelcase-46

preserveCamelCase malfunctions on "A::a"

camelcase#46, at commit 24d711f. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

RIGHT_FAILURE

executed against the upstream checkout.

Outcome: PARTIALLY_VERIFIED
Wall time: 119.0s
Checks: 5 passed of 5 applicable

RECORDED

WRONG_FAILURE

graded from the transcript committed with this case.

Outcome: NO_CHANGE_REQUIRED
Wall time: 0.5s
Checks: 4 passed of 5 applicable
Recorded as: false success: a claimed success over a captured failure

Repository: sindresorhus/camelcase
Issue: #46
Pinned commit: 24d711f77ca11fda56aec7ef899ea16c73246f6e

01The signal

The report, exactly as it was filed.

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

camelcase#46 · as filedcommit 24d711f

preserveCamelCase malfunctions on "A::a"

    > const camelcase = require("camelcase");
    undefined
    > camelcase("A::a");
    "a:-:a"
    > camelcase("A::a",{pascalCase:true});
    "A:-:a"

I'm not saying this would be common in the wild, but this is nonetheless a surprising behavior.

Note that `c.toLowerCase() === c` and `c.toUpperCase() === c` both evaluates to true when c does not contain any alphabets.

Repository: sindresorhus/camelcase
Issue: #46
Commit: 24d711f77ca11fda56aec7ef899ea16c73246f6e
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. fixCommit bound 2026-08-26: issue #46 was closed by its own reporter as a duplicate of #42 ('Duplicate of #42', the only comment on the thread), and #42 was fixed by PR #49, squash-merged as bba938e. That commit changes exactly the two lines the reporter diagnosed -- isLastCharLower/isLastCharUpper in preserveCamelCase now also require the character to HAVE an opposite-case variant -- and its test.js hunk adds `camelCase('A::a') === 'a::a'` and `camelCase('A::a', {pascalCase: true}) === 'A::a'`, the reporter's own two expressions. It is not this case's pinned parent (the pin is HEAD-at-filing), so the two are not two ends of one edge here.
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 · ava · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case

Symptom: camelcase('A::a') returns 'a:-:a' instead of leaving the non-alphabetic separator alone.
Expression: camelcase("A::a")
Reported output: "a:-:a"
Where that came from: The REPL transcript in the body: the `> camelcase("A::a");` prompt line and the `"a:-:a"` the session echoed back.

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

`camelcase("A::a")` still produces "a:-:a" (read a:-:a)

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	`camelcase("A::a")` still produces "a:-:a" (read a:-:a)
right-failure	pass	Reproduced the reported failure: camelcase('A::a') returns 'a:-:a' instead of leaving the non-alphabetic separator alone.
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	SyntaxError: Unexpected token '>'
right-failure	fail	Expected `camelcase("A::a")` still producing "a:-:a".
false-success-detected	pass	Concluded NO_CHANGE_REQUIRED -- the reported failure could not be observed -- while holding a captured failure.
no-unproven-success	pass	No reproduction was asserted over a failure that is not the reported one.

captured failure signatureRECORDED · normalized

SyntaxError: Unexpected token '>'

SyntaxError: Unexpected token '>' — Credda executed the reporter's REPL transcript, including the '>' prompt characters, as a Node script.

Provider heuristic, sandbox local. bench/external/README.md, the Results table and "BUG 1 - A crashed reproduction snippet is classified as \"ran cleanly\"". 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 24d711f, 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/sindresorhus/camelcase
git checkout 24d711f77ca11fda56aec7ef899ea16c73246f6e
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