The advertised line-break delimiter is passed to String.split as two literal characters

Summary

Sum delimiter mode exposes \n as the default line-break separator and ships multiline examples using it, but passes those two literal characters unchanged to String.split. Consequently, the exact example returns 0 instead of 19494; minimized input 1\n2 returns 0 instead of 3.

Validation source commit: 0337840e9ec0f26840252a658c1a6bf8c1b6dbf1.

Code path

• src/pages/tools/number/sum/index.tsx:33-63: UI option says the default delimiter is a line break; the shipped multiline example expects 19494 while passing the literal \n option.
• public/locales/en/number.json:166-179: Localized product documentation says numbers may be newline-separated and that the default delimiter is a line break.
• src/pages/tools/number/sum/service.ts:9-36: Delimiter mode splits directly on the unnormalized option value before summing.
• src/components/examples/ToolExamples.tsx:31-34: Example selection copies sample input and options directly into product state.
• Repository-local validation artifact: Executable witness covers the minimized counterexample, repository example, and actual-newline control.

Steps to reproduce

This report is based on a source-control-flow validation against the commit above.

1. Check out the source commit listed in this report.
2. Inspect the code path and contract anchors listed above.
3. Exercise the described boundary/state path: The advertised line-break delimiter is passed to String.split as two literal characters.
4. Compare the observed behavior with the expected contract below.

Validation note: The minimized case reports expected 3, actual 0, while an actual-newline separator control reports 3. The exact repository example reports expected 19494, actual 0. Assertions make the replay fail if these frozen observations change.

Expected behavior

The implementation should preserve the repository contract described by the documentation, public type, parser, serializer, or sibling implementation anchors above.

Actual behavior

Sum delimiter mode exposes \n as the default line-break separator and ships multiline examples using it, but passes those two literal characters unchanged to String.split. Consequently, the exact example returns 0 instead of 19494; minimized input 1\n2 returns 0 instead of 3.

Existing coverage

I did not find an existing issue or PR title that appears to cover this exact root cause in the pre-submission check.

Suggested fix

Interpret the displayed/default literal separator value n as a newline, or supply an actual newline to the service.

Suggested tests

• Add a regression test for: The advertised line-break delimiter is passed to String.split as two literal characters.
• Include the boundary value or state transition described above so the old behavior fails before the fix.

---

Submitted with Codex.