morluto/rea

Fork 0

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

[GH-ISSUE #1852] [Feature] Explain available REA static lanes after unsupported native admission #628

New issue

Closed

opened 2026-10-15 18:26:46 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-15 18:26:46 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1852

Before submitting

I searched open and closed issues and pull requests for related work.
I removed credentials, private paths, and sensitive target data.

Area

Provider or capability discovery.

Current limitation

open_binary rejects some artifact families or encoding/load combinations. The caller needs to distinguish a restriction of the selected native lane from a missing engine and from other available REA inspection capabilities.

Use cases

Continue investigating a WebAssembly artifact or a nonstandard firmware member after a typed native admission rejection.

Desired outcome and success criteria

Identify the exact format/encoding/load restriction in the typed outcome.
Point to an actually advertised compatible REA operation when one exists, with valid arguments.
Distinguish unsupported analysis from absent optional tools and remaining unverified semantics.
Do not suggest nonexistent providers or futile header edits.

Authority boundaries and non-goals

No implicit provider installation, execution, byte mutation, automatic outside-adapter fallback or fabricated support claim.

Alternatives considered

REA already has a dedicated WebAssembly inspection lane (#884); unsupported native opening does not prove absence of all REA WebAssembly capabilities.

Possible direction

Reuse capability discovery and failure classification to expose supported next steps. Related: #1587.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1852 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I removed credentials, private paths, and sensitive target data. ### Area Provider or capability discovery. ### Current limitation `open_binary` rejects some artifact families or encoding/load combinations. The caller needs to distinguish a restriction of the selected native lane from a missing engine and from other available REA inspection capabilities. ### Use cases Continue investigating a WebAssembly artifact or a nonstandard firmware member after a typed native admission rejection. ### Desired outcome and success criteria - Identify the exact format/encoding/load restriction in the typed outcome. - Point to an actually advertised compatible REA operation when one exists, with valid arguments. - Distinguish unsupported analysis from absent optional tools and remaining unverified semantics. - Do not suggest nonexistent providers or futile header edits. ### Authority boundaries and non-goals No implicit provider installation, execution, byte mutation, automatic outside-adapter fallback or fabricated support claim. ### Alternatives considered REA already has a dedicated WebAssembly inspection lane (#884); unsupported native opening does not prove absence of all REA WebAssembly capabilities. ### Possible direction Reuse capability discovery and failure classification to expose supported next steps. Related: #1587.

bsakaguchi

2026-10-15 18:26:46 +00:00

closed this issue
added the
area: providers

area: setup

triage

enhancement

P2: medium
labels

bsakaguchi commented

2026-10-15 18:26:47 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

The WASM part is addressed by #1872. The earliest cause is the shared filesystem admission probe: a recognized v1 module previously continued to generic native parsing or suffix-based classification, without identifying the separately advertised static operation. The proposed change adds the format-specific admission constraint at that producer and presents the same exact-path guidance through CLI, MCP and doctor.

Executed on Linux with pinned Node 24.18.0 / npm 11.16.0 and caller-supplied WABT 1.0.42:

102 related tests passed; one platform-specific test skipped. Coverage includes actual advertised schemas, quoted paths, negative headers, explicit raw-binary choices, missing tools and subsequent connection usability.
A fresh stdio MCP client used the JSON arguments from the native-rejection diagnostic. Empty-module inspection succeeded with complete CLI/MCP Evidence parity; missing WABT remained a distinct capability_unavailable failure.
The existing real-WABT workflow passed 24 cases and its final lineage observation found no live descendants.
Two unchanged released modules reached the advertised lane but exposed a separate parser defect: valid DataCount rows fail as unreadable_output. This is independently reproduced, reduced and tracked in #1956; full static recovery for these modules is not claimed.

This issue remains open for other unsupported firmware encoding/load combinations. Recovery must identify an actually compatible REA operation and preserve explicit caller choices and unknown semantics; it must not imply that every rejected native target has a successful alternate lane.

@N0zoM1z0 commented on GitHub (Oct 11, 2026): The WASM part is addressed by #1872. The earliest cause is the shared filesystem admission probe: a recognized v1 module previously continued to generic native parsing or suffix-based classification, without identifying the separately advertised static operation. The proposed change adds the format-specific admission constraint at that producer and presents the same exact-path guidance through CLI, MCP and doctor. Executed on Linux with pinned Node 24.18.0 / npm 11.16.0 and caller-supplied WABT 1.0.42: - 102 related tests passed; one platform-specific test skipped. Coverage includes actual advertised schemas, quoted paths, negative headers, explicit raw-binary choices, missing tools and subsequent connection usability. - A fresh stdio MCP client used the JSON arguments from the native-rejection diagnostic. Empty-module inspection succeeded with complete CLI/MCP Evidence parity; missing WABT remained a distinct `capability_unavailable` failure. - The existing real-WABT workflow passed 24 cases and its final lineage observation found no live descendants. - Two unchanged released modules reached the advertised lane but exposed a separate parser defect: valid DataCount rows fail as `unreadable_output`. This is independently reproduced, reduced and tracked in #1956; full static recovery for these modules is not claimed. This issue remains open for other unsupported firmware encoding/load combinations. Recovery must identify an actually compatible REA operation and preserve explicit caller choices and unknown semantics; it must not imply that every rejected native target has a successful alternate lane.

bsakaguchi commented

2026-10-15 18:26:47 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

The recognized WASM v1 recovery path is merged in #1872 (1f17ac82282dfda1ae2dc87d99e66a8a039c0259). CLI, MCP and Doctor now retain the typed native-admission refusal and direct the caller to the existing inspect_wasm_artifact workflow with exact preserved path arguments and caller-supplied WABT prerequisites.

Validation includes 95 final integrated tests, eight static CI tasks, generated documentation checks, 42 real WABT workflow cases, and independent CLI/MCP runs on unchanged released modules. The final PR head 2e058afd0a58f7d2f5a3205750f324e5f01b2ba7 passed all 31 checks, including CI required.

This completes the WASM recovery portion. Broader provider-specific unsupported-target remediation remains under this issue; the existing lane does not provide firmware rehosting or execute WASM.

@N0zoM1z0 commented on GitHub (Oct 11, 2026): The recognized WASM v1 recovery path is merged in #1872 (`1f17ac82282dfda1ae2dc87d99e66a8a039c0259`). CLI, MCP and Doctor now retain the typed native-admission refusal and direct the caller to the existing `inspect_wasm_artifact` workflow with exact preserved path arguments and caller-supplied WABT prerequisites. Validation includes 95 final integrated tests, eight static CI tasks, generated documentation checks, 42 real WABT workflow cases, and independent CLI/MCP runs on unchanged released modules. The final PR head `2e058afd0a58f7d2f5a3205750f324e5f01b2ba7` passed all 31 checks, including `CI required`. This completes the WASM recovery portion. Broader provider-specific unsupported-target remediation remains under this issue; the existing lane does not provide firmware rehosting or execute WASM.

bsakaguchi commented

2026-10-15 18:26:47 +00:00

Author

Owner

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

The reported recovery paths are now addressed on main:

#1872 identifies a complete WASM v1 header independently of the filename, returns the typed wasm_requires_static_inspection constraint, and names the advertised inspect_wasm_artifact operation with the caller's exact path. Missing optional WABT remains a separate capability diagnostic; native-provider installation is not suggested. Actual CLI/MCP release-artifact replay verified this separate static lane.
#1991 admits the independently verified subset of unchanged ELF32 o32 MIPS32r2 MIPS16 shared images. Unsupported relocation shapes retain precise refusals; no header edits, source replacements or implicit provider fallback are used. Real controls preserve instruction context, original pointer tags, snapshots, digests and owned cleanup.
#1987 marks readable native format refusals as file_format_rejected, reports an unsupported-target category and removes misleading missing-path advice. Actual path and permission failures keep their distinct diagnosis. Three executable-format controls passed actual CLI/MCP parity and unchanged-byte checks.

These changes distinguish available static inspection, absent optional tools, and an unsupported native interpretation. They do not establish unverified encoding, relocation, floating-point or provider semantics, and do not install tools or execute target code. Future artifact-family-specific recovery can be tracked separately with its actual source identification and advertised contract.

@N0zoM1z0 commented on GitHub (Oct 12, 2026): The reported recovery paths are now addressed on main: - #1872 identifies a complete WASM v1 header independently of the filename, returns the typed `wasm_requires_static_inspection` constraint, and names the advertised `inspect_wasm_artifact` operation with the caller's exact path. Missing optional WABT remains a separate capability diagnostic; native-provider installation is not suggested. Actual CLI/MCP release-artifact replay verified this separate static lane. - #1991 admits the independently verified subset of unchanged ELF32 o32 MIPS32r2 MIPS16 shared images. Unsupported relocation shapes retain precise refusals; no header edits, source replacements or implicit provider fallback are used. Real controls preserve instruction context, original pointer tags, snapshots, digests and owned cleanup. - #1987 marks readable native format refusals as `file_format_rejected`, reports an unsupported-target category and removes misleading missing-path advice. Actual path and permission failures keep their distinct diagnosis. Three executable-format controls passed actual CLI/MCP parity and unchanged-byte checks. These changes distinguish available static inspection, absent optional tools, and an unsupported native interpretation. They do not establish unverified encoding, relocation, floating-point or provider semantics, and do not install tools or execute target code. Future artifact-family-specific recovery can be tracked separately with its actual source identification and advertised contract.

bsakaguchi referenced this issue

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

[PR #628] [MERGED] refactor(app): split Setup and ProcessOwnership modules #2126

bsakaguchi added

enhancement

and removed

enhancement

labels

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