[PR #1510] [MERGED] fix(json): name a leading byte-order mark in rejected JSON input #2930

New issue

Closed

opened 2026-10-17 21:11:58 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:11:58 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1510
Author: @kaoru0822-kitauji
Created: 10/10/2026
Status: ✅ Merged
Merged: 10/10/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/json-input-byte-order-mark

📝 Commits (1)

6c9b5b3 fix(json): name a leading byte-order mark in rejected JSON input

📊 Changes

5 files changed (+64 additions, -5 deletions)

View changed files

📝 src/application/Utf8JsonInput.ts (+9 -0)
📝 src/application/process/ProcessCli.test.ts (+11 -0)
📝 src/application/process/ProcessCli.ts (+3 -0)
📝 src/cliJsonFile.ts (+25 -5)
📝 tests/boundary/filesystem/cliJsonInput.test.ts (+16 -0)

📄 Description

Summary

REA's strict JSON file inputs reject a leading UTF-8 byte-order mark. That is intended and pinned by the "{}" case in tests/boundary/filesystem/cliJsonInput.test.ts; this PR keeps it. The problem is the diagnostic. It was the JavaScript parser's own message, which quotes the invisible U+FEFF as the unexpected token:

$ rea project-apple-application-graph bom.json --format json
… "issues":[{"path":[],"reason":"invalid_format","message":"Unexpected token '', \"{\"invento\"... is not valid JSON","expected":"JSON"}] …

$ rea capture-process bom-scenario.json --format json
… "message":"Process input file is not valid UTF-8 JSON: …/bom-scenario.json (Unexpected token '', \"{\"executa\"... is not valid JSON). Repair the file, then try again."

The quoted token renders as nothing. Windows PowerShell 5.1 (Set-Content/Out-File -Encoding UTF8) and some editors write this mark by default, so a user or agent on a supported Windows host gets an error pointing at a character they cannot see.

Change

The three JSON readers that decode with ignoreBOM: true now detect a leading U+FEFF and report:

JSON input begins with a UTF-8 byte-order mark (EF BB BF), which strict JSON input does not accept. Save the file as UTF-8 without a byte-order mark.

parseUtf8Json (src/application/Utf8JsonInput.ts) covers whole CLI JSON files and the Evidence-bundle and snapshot JSON readers (JsonFiles).
The streamed large-file path in src/cliJsonFile.ts checks the first decoded text and raises a SyntaxError subclass, so the existing invalid-JSON branch reports it.
Process scenario and capture files (src/application/process/ProcessCli.ts) put the same sentence inside their existing envelope.

What is accepted does not change: a leading BOM is still rejected with input_reason: "invalid-json". A BOM that is not at the start of the file is still reported by the parser as before.

Verification

A new cliJsonInput boundary test covers a leading BOM in a small file and in a streamed file larger than 9 MiB. A new ProcessCli.test.ts case checks the full process message.
npx vitest run src/application src/domain passes (169 files, 2,127 tests).
npm run test:focused passes on every test under tests/ that reads CLI JSON files, Evidence bundles or JsonFiles (20 files, 173 tests), plus tests/boundary/filesystem/cliJsonInput.test.ts and tests/boundary/cli/jsonInputSize.test.ts.
npm run check:fast and npm run docs:check pass. The complexity warning on readCliJsonFile is also on main (21).
I ran project-apple-application-graph by hand on a BOM-prefixed file and got the new message.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1510 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/10/2026 **Status:** ✅ Merged **Merged:** 10/10/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/json-input-byte-order-mark` --- ### 📝 Commits (1) - [`6c9b5b3`](https://github.com/morluto/rea/commit/6c9b5b337070a1c99c4158723348c4bd17f364eb) fix(json): name a leading byte-order mark in rejected JSON input ### 📊 Changes **5 files changed** (+64 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `src/application/Utf8JsonInput.ts` (+9 -0) 📝 `src/application/process/ProcessCli.test.ts` (+11 -0) 📝 `src/application/process/ProcessCli.ts` (+3 -0) 📝 `src/cliJsonFile.ts` (+25 -5) 📝 `tests/boundary/filesystem/cliJsonInput.test.ts` (+16 -0) </details> ### 📄 Description ## Summary REA's strict JSON file inputs reject a leading UTF-8 byte-order mark. That is intended and pinned by the `"{}"` case in `tests/boundary/filesystem/cliJsonInput.test.ts`; this PR keeps it. The problem is the diagnostic. It was the JavaScript parser's own message, which quotes the invisible `U+FEFF` as the unexpected token: ``` $ rea project-apple-application-graph bom.json --format json … "issues":[{"path":[],"reason":"invalid_format","message":"Unexpected token '', \"{\"invento\"... is not valid JSON","expected":"JSON"}] … $ rea capture-process bom-scenario.json --format json … "message":"Process input file is not valid UTF-8 JSON: …/bom-scenario.json (Unexpected token '', \"{\"executa\"... is not valid JSON). Repair the file, then try again." ``` The quoted token renders as nothing. Windows PowerShell 5.1 (`Set-Content`/`Out-File -Encoding UTF8`) and some editors write this mark by default, so a user or agent on a supported Windows host gets an error pointing at a character they cannot see. ## Change The three JSON readers that decode with `ignoreBOM: true` now detect a leading `U+FEFF` and report: > JSON input begins with a UTF-8 byte-order mark (EF BB BF), which strict JSON input does not accept. Save the file as UTF-8 without a byte-order mark. - `parseUtf8Json` (`src/application/Utf8JsonInput.ts`) covers whole CLI JSON files and the Evidence-bundle and snapshot JSON readers (`JsonFiles`). - The streamed large-file path in `src/cliJsonFile.ts` checks the first decoded text and raises a `SyntaxError` subclass, so the existing invalid-JSON branch reports it. - Process scenario and capture files (`src/application/process/ProcessCli.ts`) put the same sentence inside their existing envelope. What is accepted does not change: a leading BOM is still rejected with `input_reason: "invalid-json"`. A BOM that is not at the start of the file is still reported by the parser as before. ## Verification - A new `cliJsonInput` boundary test covers a leading BOM in a small file and in a streamed file larger than 9 MiB. A new `ProcessCli.test.ts` case checks the full process message. - `npx vitest run src/application src/domain` passes (169 files, 2,127 tests). - `npm run test:focused` passes on every test under `tests/` that reads CLI JSON files, Evidence bundles or `JsonFiles` (20 files, 173 tests), plus `tests/boundary/filesystem/cliJsonInput.test.ts` and `tests/boundary/cli/jsonInputSize.test.ts`. - `npm run check:fast` and `npm run docs:check` pass. The `complexity` warning on `readCliJsonFile` is also on `main` (21). - I ran `project-apple-application-graph` by hand on a BOM-prefixed file and got the new message. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-17 21:11:58 +00:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#2930

No description provided.

Rows
Columns