[GH-ISSUE #2002] Invalid raw-binary load choices are reported as unsupported or missing targets #665

New issue

Closed

opened 2026-10-15 18:27:05 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:27:05 +00:00

Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2002

Observed behavior

Headerless load choices that the caller supplies (target_format/--target-format, architecture, entry_point) are reported as problems with the target file, with advice that does not fix them. On main e19879328, using any 64-byte file:

Invocation	Projected error
`rea analyze f.bin --target-format raw-binary --architecture arm --entry-point 0x1`	`target_unavailable` / `unsupported_target`: "Cannot open artifact: raw-binary arm entry_point 0x1 must be 4-byte aligned.", remediation "Review the reported file-format reason and select a supported, well-formed target."
same with `--architecture x86 --entry-point 0xffffffffff`	same code and category, "must fit in the x86 address width", same remediation
`rea analyze f.bin --architecture arm --entry-point 0x0` (no `--target-format`)	`target_unavailable` / `unavailable`: "architecture and entry_point apply only with format=raw-binary. Check that the path exists, is readable, and points to a supported file."

The file is readable, and any bytes are a valid raw binary; only the caller's arguments need correcting. BinaryTargetResolver labels every admitRawBinary rejection file_format_rejected (from the #1979 fix), and the format-pairing rejection has no constraint at all. Codex raised this on #1987 ("Separate raw-binary input errors from format rejection").

Expected behavior

Rejected headerless load selections project as caller input (invalid_request / invalid_input), with the reason as the message and a remediation that names the raw-binary arguments. An empty file (raw-binary requires at least one file byte) remains a target refusal.

Originally created by @kaoru0822-kitauji on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2002 ### Observed behavior Headerless load choices that the caller supplies (`target_format`/`--target-format`, `architecture`, `entry_point`) are reported as problems with the target file, with advice that does not fix them. On main `e19879328`, using any 64-byte file: | Invocation | Projected error | |---|---| | `rea analyze f.bin --target-format raw-binary --architecture arm --entry-point 0x1` | `target_unavailable` / `unsupported_target`: "Cannot open artifact: raw-binary arm entry_point 0x1 must be 4-byte aligned.", remediation "Review the reported file-format reason and select a supported, well-formed target." | | same with `--architecture x86 --entry-point 0xffffffffff` | same code and category, "must fit in the x86 address width", same remediation | | `rea analyze f.bin --architecture arm --entry-point 0x0` (no `--target-format`) | `target_unavailable` / `unavailable`: "architecture and entry_point apply only with format=raw-binary. Check that the path exists, is readable, and points to a supported file." | The file is readable, and any bytes are a valid raw binary; only the caller's arguments need correcting. `BinaryTargetResolver` labels every `admitRawBinary` rejection `file_format_rejected` (from the #1979 fix), and the format-pairing rejection has no constraint at all. Codex raised this on #1987 ("Separate raw-binary input errors from format rejection"). ### Expected behavior Rejected headerless load selections project as caller input (`invalid_request` / `invalid_input`), with the reason as the message and a remediation that names the raw-binary arguments. An empty file (`raw-binary requires at least one file byte`) remains a target refusal.

bsakaguchi

2026-10-15 18:27:05 +00:00

closed this issue
added the
bug
label

bsakaguchi commented

2026-10-15 18:27:06 +00:00

Author

Owner

@jimpablo commented on GitHub (Oct 12, 2026):

I'd like to work on this.

The misclassification has two producers in src/application/BinaryTargetResolver.ts:

Every admitRawBinary rejection is wrapped with constraint: "file_format_rejected" (the formatHint === "raw-binary" branch), so caller-input problems — missing architecture, malformed entry_point, misalignment, address-width overflow — project as unsupported_target / target_unavailable with "review the file" remediation. Of those rejections, only the empty-file extent ("raw-binary requires at least one file byte") is actually a property of the target.
The pairing rejection ("architecture and entry_point apply only with format=raw-binary") carries no constraint at all, so it falls to the default BinaryTargetError projection: unavailable / target_unavailable plus "Check that the path exists…". The MCP contract layer already rejects this pairing as input (sessionLifecycleInputs superRefine via rawBinarySelectionError); the resolver duplicates that message without the classification.

Planned change:

src/domain/rawBinary.ts: admitRawBinary rejections become structured — reason plus the owning classification. Caller-input rejections get a new raw_binary_load_rejected constraint; the empty-file extent keeps file_format_rejected.
BinaryTargetResolver: raw-binary load rejections — including the format/target-kind pairing and the architecture/entry pairing (reusing rawBinarySelectionError as the single message owner) — carry raw_binary_load_rejected.
Projection (analysisErrorPresentation / analysisErrorProjection): raw_binary_load_rejected maps to category invalid_input, code invalid_request, with remediation naming the raw-binary arguments (target_format, architecture, entry_point) and no path-checking advice.
Boundary tests over the public projection for the misaligned arm entry, the x86 address-width overflow, the pairing-without-format case, and the empty file (which stays a target refusal), plus real rea analyze runs before/after on a 64-byte fixture.

@jimpablo commented on GitHub (Oct 12, 2026): I'd like to work on this. The misclassification has two producers in `src/application/BinaryTargetResolver.ts`: 1. Every `admitRawBinary` rejection is wrapped with `constraint: "file_format_rejected"` (the `formatHint === "raw-binary"` branch), so caller-input problems — missing architecture, malformed `entry_point`, misalignment, address-width overflow — project as `unsupported_target` / `target_unavailable` with "review the file" remediation. Of those rejections, only the empty-file extent ("raw-binary requires at least one file byte") is actually a property of the target. 2. The pairing rejection ("architecture and entry_point apply only with format=raw-binary") carries no constraint at all, so it falls to the default `BinaryTargetError` projection: `unavailable` / `target_unavailable` plus "Check that the path exists…". The MCP contract layer already rejects this pairing as input (`sessionLifecycleInputs` superRefine via `rawBinarySelectionError`); the resolver duplicates that message without the classification. Planned change: - `src/domain/rawBinary.ts`: `admitRawBinary` rejections become structured — `reason` plus the owning classification. Caller-input rejections get a new `raw_binary_load_rejected` constraint; the empty-file extent keeps `file_format_rejected`. - `BinaryTargetResolver`: raw-binary load rejections — including the format/target-kind pairing and the architecture/entry pairing (reusing `rawBinarySelectionError` as the single message owner) — carry `raw_binary_load_rejected`. - Projection (`analysisErrorPresentation` / `analysisErrorProjection`): `raw_binary_load_rejected` maps to category `invalid_input`, code `invalid_request`, with remediation naming the raw-binary arguments (`target_format`, `architecture`, `entry_point`) and no path-checking advice. - Boundary tests over the public projection for the misaligned arm entry, the x86 address-width overflow, the pairing-without-format case, and the empty file (which stays a target refusal), plus real `rea analyze` runs before/after on a 64-byte fixture.

bsakaguchi referenced this issue

2026-10-16 21:14:53 +00:00

[PR #665] [MERGED] fix(reference): recognize CMake build manifests #2148

bsakaguchi referenced this issue

2026-10-16 21:15:12 +00:00

[PR #692] [MERGED] fix(reference): classify test suffixes before extensions #2173

bsakaguchi referenced this issue

2026-10-16 21:15:13 +00:00

[PR #694] [MERGED] fix(reference): bound Dockerfile language detection #2174