morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5473] [Docs] Process-input error catalogue marks stale replacement wording as verified #3328

New issue

Closed

opened 2026-10-31 00:39:13 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:39:13 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5473

Before submitting

I searched the existing issues for a related documentation report.
I removed credentials, tokens, private paths, and sensitive target data.

Documentation location

docs/user-visible-errors.csv:74, harm_rank 61, location src/application/process/ProcessCli.ts:readJson read, trigger “Process scenario or evidence file cannot be read”.

Problem

This row marks implementation_status as implemented and verification_result as verified by focused CLI test, but its proposed_replacement is:

Process input file could not be read. Check that the path exists and is readable.

An independent verifier ran capture-process with a nonexistent scenario file and received the detailed diagnostic below instead. The focused test also expects the selected path and ENOENT. The stale completed replacement/verification claim misleads readers auditing the error catalogue. This is a bounded documentation discrepancy; the handled invalid-input response itself was not established as incorrect.

Expected content

Proposed correction: reconcile the row's replacement text, implementation status, and verification description with the supported diagnostic and the actual scope of the focused test. If this replacement is historical or superseded, identify that status explicitly. Keep historical current_copy distinct from the implemented replacement; its difference from current output alone does not establish a defect. This report does not request suppressing caller-selected paths or filesystem diagnostics.

Supporting evidence

Independently reproduced once using the prebuilt runtime at source commit 074768901f3cdc8205b61773fb1faf6f6c7b3ca8, REA 6.7.0, Node.js v26.12.0, Darwin arm64. The verifier used disposable home/config/data/cache/state directories and explicit disposable config/database paths. No provider or target executable was involved.

The executed command was the following, with $probe_root referring to the verifier's disposable directory and the scenario file left absent:

HOME="$probe_root/home" \
XDG_CONFIG_HOME="$probe_root/config" \
XDG_DATA_HOME="$probe_root/data" \
XDG_CACHE_HOME="$probe_root/cache" \
XDG_STATE_HOME="$probe_root/state" \
REA_CONFIG_PATH="$probe_root/config/rea.json" \
REA_DB_PATH="$probe_root/data/rea.db" \
node scripts/rea.mjs capture-process "$probe_root/missing-scenario.json" --format json

Observed: exit 1, empty stderr, and JSON stdout containing error: "Process command failed", category: "invalid_input", and this message (the disposable path is normalized to <scenario>):

Process input file could not be read: <scenario> (ENOENT: no such file or directory, open '<scenario>'). Check the reported filesystem constraint and retry.

Source-derived corroboration: src/application/process/ProcessCli.ts:223-247 constructs the detailed message; tests/boundary/filesystem/processCliFileInput.test.ts:158-165 expects the path and ENOENT. The verifier inspected that test; no test-suite execution is claimed. The CSV row was independently parsed with csv.DictReader to confirm column identity and metadata.

Before submission, upstream main was fetched at 052956af3416fa01d93837e54fdec3ad2739f6d1. No commits since the tested baseline changed the CSV, process reader, command registration, or cited focused test; the stale row and source assertion remain present. No new runtime execution on that later revision is claimed.

Additional context

Prepared with AI assistance and independently reproduced. Related runtime issue https://github.com/morluto/rea/issues/5397 covers missing machine-readable error fields for the same command and is separate: adding those fields would leave this stale documentation claim. Issue #5077 concerns the adjacent removed 64 MiB limit row, rather than this unreadable-file replacement.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5473 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location `docs/user-visible-errors.csv:74`, `harm_rank` 61, location `src/application/process/ProcessCli.ts:readJson read`, trigger “Process scenario or evidence file cannot be read”. ### Problem This row marks `implementation_status` as `implemented` and `verification_result` as `verified by focused CLI test`, but its `proposed_replacement` is: > Process input file could not be read. Check that the path exists and is readable. An independent verifier ran `capture-process` with a nonexistent scenario file and received the detailed diagnostic below instead. The focused test also expects the selected path and ENOENT. The stale completed replacement/verification claim misleads readers auditing the error catalogue. This is a bounded documentation discrepancy; the handled invalid-input response itself was not established as incorrect. ### Expected content Proposed correction: reconcile the row's replacement text, implementation status, and verification description with the supported diagnostic and the actual scope of the focused test. If this replacement is historical or superseded, identify that status explicitly. Keep historical `current_copy` distinct from the implemented replacement; its difference from current output alone does not establish a defect. This report does not request suppressing caller-selected paths or filesystem diagnostics. ### Supporting evidence Independently reproduced once using the prebuilt runtime at source commit `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`, REA 6.7.0, Node.js v26.12.0, Darwin arm64. The verifier used disposable home/config/data/cache/state directories and explicit disposable config/database paths. No provider or target executable was involved. The executed command was the following, with `$probe_root` referring to the verifier's disposable directory and the scenario file left absent: ```sh HOME="$probe_root/home" \ XDG_CONFIG_HOME="$probe_root/config" \ XDG_DATA_HOME="$probe_root/data" \ XDG_CACHE_HOME="$probe_root/cache" \ XDG_STATE_HOME="$probe_root/state" \ REA_CONFIG_PATH="$probe_root/config/rea.json" \ REA_DB_PATH="$probe_root/data/rea.db" \ node scripts/rea.mjs capture-process "$probe_root/missing-scenario.json" --format json ``` Observed: exit 1, empty stderr, and JSON stdout containing `error: "Process command failed"`, `category: "invalid_input"`, and this message (the disposable path is normalized to `<scenario>`): ```text Process input file could not be read: <scenario> (ENOENT: no such file or directory, open '<scenario>'). Check the reported filesystem constraint and retry. ``` Source-derived corroboration: `src/application/process/ProcessCli.ts:223-247` constructs the detailed message; `tests/boundary/filesystem/processCliFileInput.test.ts:158-165` expects the path and ENOENT. The verifier inspected that test; no test-suite execution is claimed. The CSV row was independently parsed with `csv.DictReader` to confirm column identity and metadata. Before submission, upstream `main` was fetched at `052956af3416fa01d93837e54fdec3ad2739f6d1`. No commits since the tested baseline changed the CSV, process reader, command registration, or cited focused test; the stale row and source assertion remain present. No new runtime execution on that later revision is claimed. ### Additional context Prepared with AI assistance and independently reproduced. Related runtime issue https://github.com/morluto/rea/issues/5397 covers missing machine-readable error fields for the same command and is separate: adding those fields would leave this stale documentation claim. Issue #5077 concerns the adjacent removed 64 MiB limit row, rather than this unreadable-file replacement.

bsakaguchi closed this issue

2026-10-31 00:39:13 +00:00

bsakaguchi commented

2026-10-31 00:39:14 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 20, 2026):

Additional stale rows in the same catalogue

The three additional verifier reports identify two distinct rows: the two malformed-JSON reports refer to the same harm_rank 63 entry. Neither row is covered above. Checked against REA 6.7.0 at 074768901f3cdc8205b61773fb1faf6f6c7b3ca8:

docs/user-visible-errors.csv:76, harm_rank 63, ProcessCli.ts:readJson parse — trigger: malformed process scenario or evidence JSON. The proposed replacement is Process input file is not valid JSON. Repair the file, then try again., marked implemented / verified by focused CLI test. I re-ran capture-process <scenario> --format json with each verifier's malformed JSON input in isolated storage; both exited 1 with empty stderr and category: invalid_input. For the input {this is not valid json, the actual message was (selected path normalized):
```
Process input file is not valid UTF-8 JSON: <scenario> (Expected property name or '}' in JSON at position 1 (line 1 column 2)). Repair the file, then try again.
```
The other malformed input likewise retained its path and parser detail. ProcessCli.ts:223-245 constructs this diagnostic, and tests/boundary/filesystem/processCliFileInput.test.ts:167-172 expects the path-bearing UTF-8 prefix. Proposed correction: reconcile the replacement, completion status and verification description with that supported diagnostic and coverage.
docs/user-visible-errors.csv:79, harm_rank 67, ProcessCli.ts:unexpected — trigger: an unexpected parser/comparison/canonicalization failure escapes the expected classifications. The proposed replacement is “Process command could not complete. Check the input files and run rea doctor, then try again.”, marked implemented / verified by direct unexpected-cause projection test. Static proof only for the CLI behavior; no unexpected-failure CLI reproduction was executed. ProcessCli.ts:264-278 instead constructs:
```
Process command could not complete: <cause message>
```
describeValidationFailure preserves an Error's message, and tests/boundary/filesystem/processCliFileInput.test.ts:19-31 explicitly asserts that diagnostic retention. I re-checked these source/test assertions; I did not re-run the test suite. Proposed correction: align the row's replacement, completion status and verification description with what that test actually establishes.

These share the same documentation closure: update the catalogue rows. Historical current_copy differences alone are not defects, and this does not request changing runtime diagnostic retention. Runtime issues #5397 and #5398 are separate.

@coygeek commented on GitHub (Oct 20, 2026): ### Additional stale rows in the same catalogue The three additional verifier reports identify **two distinct rows**: the two malformed-JSON reports refer to the same `harm_rank` 63 entry. Neither row is covered above. Checked against REA 6.7.0 at `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`: 1. **`docs/user-visible-errors.csv:76`, `harm_rank` 63, `ProcessCli.ts:readJson parse`** — trigger: malformed process scenario or evidence JSON. The proposed replacement is `Process input file is not valid JSON. Repair the file, then try again.`, marked `implemented` / `verified by focused CLI test`. I re-ran `capture-process <scenario> --format json` with each verifier's malformed JSON input in isolated storage; both exited 1 with empty stderr and `category: invalid_input`. For the input `{this is not valid json`, the actual message was (selected path normalized): ```text Process input file is not valid UTF-8 JSON: <scenario> (Expected property name or '}' in JSON at position 1 (line 1 column 2)). Repair the file, then try again. ``` The other malformed input likewise retained its path and parser detail. `ProcessCli.ts:223-245` constructs this diagnostic, and `tests/boundary/filesystem/processCliFileInput.test.ts:167-172` expects the path-bearing UTF-8 prefix. Proposed correction: reconcile the replacement, completion status and verification description with that supported diagnostic and coverage. 2. **`docs/user-visible-errors.csv:79`, `harm_rank` 67, `ProcessCli.ts:unexpected`** — trigger: an unexpected parser/comparison/canonicalization failure escapes the expected classifications. The proposed replacement is “Process command could not complete. Check the input files and run `rea doctor`, then try again.”, marked `implemented` / `verified by direct unexpected-cause projection test`. **Static proof only for the CLI behavior; no unexpected-failure CLI reproduction was executed.** `ProcessCli.ts:264-278` instead constructs: ```text Process command could not complete: <cause message> ``` `describeValidationFailure` preserves an Error's message, and `tests/boundary/filesystem/processCliFileInput.test.ts:19-31` explicitly asserts that diagnostic retention. I re-checked these source/test assertions; I did not re-run the test suite. Proposed correction: align the row's replacement, completion status and verification description with what that test actually establishes. These share the same documentation closure: update the catalogue rows. Historical `current_copy` differences alone are not defects, and this does not request changing runtime diagnostic retention. Runtime issues #5397 and #5398 are separate.

bsakaguchi commented

2026-10-31 00:39:14 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 20, 2026):

One more stale row in the same catalogue

docs/user-visible-errors.csv:75, harm_rank 62, location src/application/process/ProcessCli.ts:readJson size, records the trigger Process scenario or evidence file exceeds 64 MiB. It marks Process input file is too large. Reduce it below 64 MiB, then try again. as implemented, with verification_result set to verified by focused sparse-file CLI test.

I re-ran node scripts/rea.mjs capture-process <scenario> --format json for both inputs below using isolated home/config/data/cache/state directories, REA 6.7.0 at 074768901f3cdc8205b61773fb1faf6f6c7b3ca8, and Node.js v26.12.0. Each exited 1 with empty stderr and category invalid_input:

A 67,108,865-byte sparse file returned the following message, with the selected path normalized:

Process input file is not valid UTF-8 JSON: <scenario> (Parser cannot parse input: expected a value). Repair the file, then try again.

A 67,108,868-byte valid JSON document, null followed by spaces, reached scenario validation. It returned code invalid_request, message Analysis input is invalid. Check the arguments and try again., and an issue with path [], reason invalid_type, and expected object.

Neither emitted the recorded size error. The valid-JSON control confirms that exceeding the stated threshold alone did not trigger that rejection. Source corroboration: JsonInputFile.ts:33-35 identifies its 8 MiB threshold as a parser-selection budget, and readJsonInputFile streams larger inputs.

Proposed correction: reconcile this row's size trigger, replacement, implementation status and verification claim with current behavior, or explicitly mark the fixed-size rejection as historical or removed. This is a P3 documentation discrepancy; these probes do not establish a runtime size-handling defect or justify restoring the obsolete limit.

This shares the same closure: update the catalogue rows. Runtime issues #5397 and #5398 are separate.

@coygeek commented on GitHub (Oct 20, 2026): ### One more stale row in the same catalogue `docs/user-visible-errors.csv:75`, `harm_rank` 62, location `src/application/process/ProcessCli.ts:readJson size`, records the trigger `Process scenario or evidence file exceeds 64 MiB`. It marks `Process input file is too large. Reduce it below 64 MiB, then try again.` as `implemented`, with `verification_result` set to `verified by focused sparse-file CLI test`. I re-ran `node scripts/rea.mjs capture-process <scenario> --format json` for both inputs below using isolated home/config/data/cache/state directories, REA 6.7.0 at `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`, and Node.js v26.12.0. Each exited 1 with empty stderr and category `invalid_input`: - A 67,108,865-byte sparse file returned the following message, with the selected path normalized: ```text Process input file is not valid UTF-8 JSON: <scenario> (Parser cannot parse input: expected a value). Repair the file, then try again. ``` - A 67,108,868-byte valid JSON document, `null` followed by spaces, reached scenario validation. It returned code `invalid_request`, message `Analysis input is invalid. Check the arguments and try again.`, and an issue with path `[]`, reason `invalid_type`, and expected `object`. Neither emitted the recorded size error. The valid-JSON control confirms that exceeding the stated threshold alone did not trigger that rejection. Source corroboration: `JsonInputFile.ts:33-35` identifies its 8 MiB threshold as a parser-selection budget, and `readJsonInputFile` streams larger inputs. Proposed correction: reconcile this row's size trigger, replacement, implementation status and verification claim with current behavior, or explicitly mark the fixed-size rejection as historical or removed. This is a P3 documentation discrepancy; these probes do not establish a runtime size-handling defect or justify restoring the obsolete limit. This shares the same closure: update the catalogue rows. Runtime issues #5397 and #5398 are separate.

bsakaguchi commented

2026-10-31 00:39:14 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

All four rows covered by body/comments have been reconciled: 61 preserves path/filesystem detail; 63 preserves UTF-8/JSON/path detail; 62 describes live heap admission and explicitly supersedes the former 64 MiB refusal; 67 describes sanitized cause plus current no-repeat recovery. Current ProcessCli producer and focused assertions agree. This is documentation resolution, not proof that every large file succeeds or a new runtime semantics change.

Implementation: user-visible-errors.csv, user-visible-errors.csv.

The relevant regression checks in processCliFileInput.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. All four rows covered by body/comments have been reconciled: 61 preserves path/filesystem detail; 63 preserves UTF-8/JSON/path detail; 62 describes live heap admission and explicitly supersedes the former 64 MiB refusal; 67 describes sanitized cause plus current no-repeat recovery. Current ProcessCli producer and focused assertions agree. This is documentation resolution, not proof that every large file succeeds or a new runtime semantics change. Implementation: [user-visible-errors.csv](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/docs/user-visible-errors.csv#L74), [user-visible-errors.csv](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/docs/user-visible-errors.csv#L75). The relevant regression checks in [processCliFileInput.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/filesystem/processCliFileInput.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 01:10:29 +00:00

[PR #3822] [MERGED] fix(javascript): keep the request endpoint on a uniquely consumed response #5924

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#3328

No description provided.

Rows
Columns