[GH-ISSUE #8507] [Bug] Firmware capability recovery recommends the wrong alternative engine #6632

New issue

Closed

opened 2026-11-01 21:12:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:49 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8507

Before submitting

Searched open and closed issues for related reports.
Removed credentials, private paths, and sensitive target data.

Area

Provider or capability discovery

Observed behavior

Firmware capability discovery recommends configuring Binwalk or Unblob for either missing firmware operation. REA's execution contract requires a specific engine: inspect_firmware_regions uses Binwalk; extract_firmware uses Unblob. Configuring the other engine cannot enable the requested operation.

Both directions were reproduced at the capability projection boundary. This is about REA's adapter contracts, not a claim that the upstream programs have no overlapping features.

Reproduction

Executed current source buildCapabilityInventory({open:false, capabilities:[]}, policy) with three configurations:

Configured engine flags	`inspect_firmware_regions`	`extract_firmware`
Unblob only	Unavailable; advises Binwalk or Unblob	Available
Binwalk only	Available	Unavailable; advises Binwalk or Unblob
Both	Available	Available

The policy uses the same independent flags produced by src/composition/capabilityServices.ts. These are controlled capability projections, not real engine installations or Linux extraction runs.

Expected behavior

For inspection, name REA_BINWALK_COMMAND and Binwalk's actual prerequisites. For extraction, name REA_UNBLOB_COMMAND, Unblob's prerequisites and relevant extractors. Preserve the separate supported-host diagnosis.

Share the operation-to-engine requirement between discovery and execution so a future engine change cannot leave recovery advice behind. Following the proposed alternative should be capable of enabling the original operation.

Impact and scope

When one engine is already configured, discovery can recommend that same engine as a way to repair the unavailable operation that requires the other one. Agents can repeat setup without changing the actual blocker. Reproduced in both directions; the both-engines case is a working control. Real user frequency and Linux provider execution were not measured.

REA version

Source 3842809c371a59609f576a9db8f9c492a3f071e6; relevant provider/inventory files unchanged at fetched main 53363166f068a21f00a605187e1c3af428aa7d5d.

Runtime and platform

Node 24.22.1, Darwin arm64; pure shared capability projection with explicit configuration facts.

Target and artifact context

No firmware artifact was opened or extracted.

Interface

Other: shared capability inventory used by CLI/MCP.

Earliest failure stage

Transport or result projection

Relevant output or evidence

For both unavailable entries, the returned recovery is:

On Linux, provide an absolute REA_BINWALK_COMMAND (Binwalk 3.1.x, verified with 3.1.0) or REA_UNBLOB_COMMAND (Unblob 26.6.x, verified with 26.6.4) path and util-linux prlimit. Extraction also requires the selected format’s external extractor.

The mapping is explicit in FirmwareProvider.ts:335 and the named tool contracts. CapabilityInventory.ts:583 selects the correct availability flag but uses one combined OR-remediation for both operations.

Analysis or suspected cause

Discovery preserves operation-specific availability but erases the operation-specific requirement when constructing the next action. This differs from #8506, where existing producer recovery is lost during projection. Both should be checked through final capability output and by following the suggested recovery when the required host/tools are available.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8507 ### Before submitting - [x] Searched open and closed issues for related reports. - [x] Removed credentials, private paths, and sensitive target data. ### Area Provider or capability discovery ### Observed behavior Firmware capability discovery recommends configuring **Binwalk or Unblob** for either missing firmware operation. REA's execution contract requires a specific engine: `inspect_firmware_regions` uses Binwalk; `extract_firmware` uses Unblob. Configuring the other engine cannot enable the requested operation. Both directions were reproduced at the capability projection boundary. This is about REA's adapter contracts, not a claim that the upstream programs have no overlapping features. ### Reproduction Executed current source `buildCapabilityInventory({open:false, capabilities:[]}, policy)` with three configurations: | Configured engine flags | `inspect_firmware_regions` | `extract_firmware` | | --- | --- | --- | | Unblob only | Unavailable; advises Binwalk **or Unblob** | Available | | Binwalk only | Available | Unavailable; advises Binwalk **or Unblob** | | Both | Available | Available | The policy uses the same independent flags produced by `src/composition/capabilityServices.ts`. These are controlled capability projections, not real engine installations or Linux extraction runs. ### Expected behavior For inspection, name `REA_BINWALK_COMMAND` and Binwalk's actual prerequisites. For extraction, name `REA_UNBLOB_COMMAND`, Unblob's prerequisites and relevant extractors. Preserve the separate supported-host diagnosis. Share the operation-to-engine requirement between discovery and execution so a future engine change cannot leave recovery advice behind. Following the proposed alternative should be capable of enabling the original operation. ### Impact and scope When one engine is already configured, discovery can recommend that same engine as a way to repair the unavailable operation that requires the other one. Agents can repeat setup without changing the actual blocker. Reproduced in both directions; the both-engines case is a working control. Real user frequency and Linux provider execution were not measured. ### REA version Source `3842809c371a59609f576a9db8f9c492a3f071e6`; relevant provider/inventory files unchanged at fetched main `53363166f068a21f00a605187e1c3af428aa7d5d`. ### Runtime and platform Node 24.22.1, Darwin arm64; pure shared capability projection with explicit configuration facts. ### Target and artifact context No firmware artifact was opened or extracted. ### Interface Other: shared capability inventory used by CLI/MCP. ### Earliest failure stage Transport or result projection ### Relevant output or evidence For both unavailable entries, the returned recovery is: ```text On Linux, provide an absolute REA_BINWALK_COMMAND (Binwalk 3.1.x, verified with 3.1.0) or REA_UNBLOB_COMMAND (Unblob 26.6.x, verified with 26.6.4) path and util-linux prlimit. Extraction also requires the selected format’s external extractor. ``` The mapping is explicit in [`FirmwareProvider.ts:335`](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/src/firmware/FirmwareProvider.ts#L335) and the [named tool contracts](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/src/contracts/firmware/firmwareToolContracts.ts). [`CapabilityInventory.ts:583`](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/src/application/CapabilityInventory.ts#L583) selects the correct availability flag but uses one combined OR-remediation for both operations. ### Analysis or suspected cause Discovery preserves operation-specific availability but erases the operation-specific requirement when constructing the next action. This differs from #8506, where existing producer recovery is lost during projection. Both should be checked through final capability output and by following the suggested recovery when the required host/tools are available.

bsakaguchi added the

bug

triage

labels

2026-11-01 21:12:49 +00:00

bsakaguchi referenced this issue

2026-11-01 21:47:27 +00:00

[PR #6632] [CLOSED] fix(mcp): advertise attached-capture incompleteness in compare_web_captures example #7384

bsakaguchi referenced this issue

2026-11-03 00:29:36 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi closed this issue