morluto/rea

Fork 0

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

[GH-ISSUE #8549] [Bug] Evidence summary suggests unsupported analysis view for xrefs #6642

New issue

Open

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

bsakaguchi commented

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

Owner

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

Current main: exact record retrieval

Merged #8528 adds get_evidence_bundle with detail: "records" and an exact evidence_id filter. On current main 85013da0c, a real Ghidra 12.1.4 control captured xrefs, procedure_references, and read_bytes, exported them, and imported the bundle into a fresh target-free MCP session. In both compact and full output-schema profiles, each exact-ID record selection returned the original complete record unchanged, with missing_evidence_links: [] and explicit historical/non-importable-selection limitations. No provider was opened in the importing session. For this three-record fixture, the selected results were 4,081, 5,684, and 4,080 serialized bytes respectively; these are not token or timing measurements. inspect_analysis_view still rejected those three parents, as expected.

This supersedes the earlier full-bundle-only recovery observation below. The remaining issue is the unqualified catalog and summary guidance, which still says to use discovered IDs with inspect_analysis_view without limiting that to supported parent operations. Use detail: "records" for an individual complete record; use export for a portable bundle or a record that exceeds the response budget.

Oversized selected-record recovery

On current main 85013da0c, a fresh target-free MCP session imported the previously captured real Ghidra 6 MiB read_bytes Evidence and selected it by exact ID with detail: "records", under a 10 MiB server response budget. In compact and full output-schema profiles, the single record exceeded the response budget and returned typed resource_constraint recovery explicitly saying a single oversized record needs export. export_evidence_bundle then preserved the complete original Evidence byte-for-byte; the session remained target-free and the source bundle unchanged. This tests one oversized real-provider record and recovery, not provider peak memory or every large-record producer.

Before submitting

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

Area

MCP or agent integration

Observed behavior

get_evidence_bundle advertises summary discovery followed by inspect_analysis_view using a discovered Evidence ID, without qualifying which parent operations support views. A real retained xrefs record is discoverable, but both summary and native-inventory view requests return nonretryable unsupported_target: Parent Evidence operation "xrefs" does not support analysis views.

Reproduction

On REA #8509 head 7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796, macOS arm64, Node 24.22.1 and Kuna 1.988:

Open an owned Mach-O, call xrefs for a function, and export the Evidence bundle. Close the session.
In a fresh target-free compact stdio MCP session, import the bundle and call get_evidence_bundle with detail: "summary" and the xrefs evidence_id filter. It returns one complete-record summary.
Call inspect_analysis_view with source: {kind: "retained-evidence", evidence_id: <that id>} and view: {kind: "summary"} or {kind: "native-inventory", offset: 0, limit: 1}. Both return the error above.

The fixture contained 100 incoming call references; the binary digest remained unchanged and it was never executed. The same outcome was observed in an unmerged prototype, but the steps above also use the unchanged branch.

Ghidra reference handoff control

On REA 96ba4225, Ghidra 12.1.4 and macOS arm64, real stdio MCP captured an exact xrefs result and a procedure_references outgoing result for an owned Mach-O, exported the bundle, then imported it into a fresh target-free server. In both compact and full output-schema profiles, exact-ID summaries found each retained record and unfiltered complete delivery preserved each complete Evidence record exactly, including the detailed reference endpoints and kinds. The fresh session reported no open target. inspect_analysis_view with kind: summary returned unsupported_target for both operations. The serialized complete bundle result was 8,808 bytes for this two-record fixture; this is not a token or performance measurement. Target SHA-256 4818a9e2164a816dd1274b5384999832ec7ba2b6558435c8f074fddbd073171a remained unchanged and it was not executed.

This extends the observed unsupported-view case from Kuna xrefs to Ghidra procedure_references; it does not imply that every reference record needs a custom view. A full bundle remains a working handoff, while #8569 considers a distinct bounded range-reference task.

Expected behavior

Guide callers to a supported follow-up for the specific record, or state that views only support selected operations. Exporting the complete retained bundle is an existing recovery path. Separately consider whether a bounded incoming-reference view is justified; this report does not assume every Evidence operation needs a view.

Impact and scope

An agent following the advertised summary handoff encounters a nonretryable dead end for this xrefs Evidence. A complete bundle export remains available. One compact-profile test on one host and one operation; other records, autonomous agent behavior, and prevalence are unverified.

REA version

7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796 (#8509).

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.988.

Target and artifact context

Owned static arm64 Mach-O executable, SHA-256 3d39bb659d0ec6fdc907ef9ea3d88c2f59fa1b3b870a6f743f518c227c3b18af, unchanged and unexecuted.

Interface

MCP

Earliest failure stage

Tool description and cross-tool discovery guidance; the explicit unsupported-target error correctly reflects current view support.

Relevant output or evidence

get_evidence_bundle: matching_records: 1, operation xrefs, retention: "complete-record". Both follow-up view requests: unsupported_target, retryable: false. The tool description says to use a discovered ID with inspect_analysis_view without specifying the parent-operation restriction.

Typed outcome or recovery expected

Clear supported-operation guidance and a usable route for a discovered record. Consider how to identify compatible views and retrieve selected source facts without materializing every record, while retaining complete Evidence and honest coverage.

Analysis or suspected cause

Source inspection: the catalog description gives unqualified guidance; inspect_analysis_view checks parent-operation support and correctly refuses xrefs. The documentation in docs/mcp-contracts.md repeats the unqualified guidance. This does not establish that xrefs must become a view-supported operation.

Additional context

Related: #8348 (making incoming reference observations actionable) and #8510 (stored-pointer omission). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8549 ### Current main: exact record retrieval Merged #8528 adds `get_evidence_bundle` with `detail: "records"` and an exact `evidence_id` filter. On current main `85013da0c`, a real Ghidra 12.1.4 control captured `xrefs`, `procedure_references`, and `read_bytes`, exported them, and imported the bundle into a fresh target-free MCP session. In both compact and full output-schema profiles, each exact-ID record selection returned the original complete record unchanged, with `missing_evidence_links: []` and explicit historical/non-importable-selection limitations. No provider was opened in the importing session. For this three-record fixture, the selected results were 4,081, 5,684, and 4,080 serialized bytes respectively; these are not token or timing measurements. `inspect_analysis_view` still rejected those three parents, as expected. This supersedes the earlier full-bundle-only recovery observation below. The remaining issue is the unqualified catalog and summary guidance, which still says to use discovered IDs with `inspect_analysis_view` without limiting that to supported parent operations. Use `detail: "records"` for an individual complete record; use export for a portable bundle or a record that exceeds the response budget. ### Oversized selected-record recovery On current main `85013da0c`, a fresh target-free MCP session imported the previously captured real Ghidra 6 MiB `read_bytes` Evidence and selected it by exact ID with `detail: "records"`, under a 10 MiB server response budget. In compact and full output-schema profiles, the single record exceeded the response budget and returned typed `resource_constraint` recovery explicitly saying a single oversized record needs export. `export_evidence_bundle` then preserved the complete original Evidence byte-for-byte; the session remained target-free and the source bundle unchanged. This tests one oversized real-provider record and recovery, not provider peak memory or every large-record producer. ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior `get_evidence_bundle` advertises summary discovery followed by `inspect_analysis_view` using a discovered Evidence ID, without qualifying which parent operations support views. A real retained `xrefs` record is discoverable, but both summary and native-inventory view requests return nonretryable `unsupported_target`: `Parent Evidence operation "xrefs" does not support analysis views.` ### Reproduction On REA #8509 head `7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796`, macOS arm64, Node 24.22.1 and Kuna 1.988: 1. Open an owned Mach-O, call `xrefs` for a function, and export the Evidence bundle. Close the session. 2. In a fresh target-free compact stdio MCP session, import the bundle and call `get_evidence_bundle` with `detail: "summary"` and the xrefs `evidence_id` filter. It returns one complete-record summary. 3. Call `inspect_analysis_view` with `source: {kind: "retained-evidence", evidence_id: <that id>}` and `view: {kind: "summary"}` or `{kind: "native-inventory", offset: 0, limit: 1}`. Both return the error above. The fixture contained 100 incoming call references; the binary digest remained unchanged and it was never executed. The same outcome was observed in an unmerged prototype, but the steps above also use the unchanged branch. ### Ghidra reference handoff control On REA `96ba4225`, Ghidra 12.1.4 and macOS arm64, real stdio MCP captured an exact `xrefs` result and a `procedure_references` outgoing result for an owned Mach-O, exported the bundle, then imported it into a fresh target-free server. In both compact and full output-schema profiles, exact-ID summaries found each retained record and unfiltered complete delivery preserved each complete Evidence record exactly, including the detailed reference endpoints and kinds. The fresh session reported no open target. `inspect_analysis_view` with `kind: summary` returned `unsupported_target` for both operations. The serialized complete bundle result was 8,808 bytes for this two-record fixture; this is not a token or performance measurement. Target SHA-256 `4818a9e2164a816dd1274b5384999832ec7ba2b6558435c8f074fddbd073171a` remained unchanged and it was not executed. This extends the observed unsupported-view case from Kuna `xrefs` to Ghidra `procedure_references`; it does not imply that every reference record needs a custom view. A full bundle remains a working handoff, while #8569 considers a distinct bounded range-reference task. ### Expected behavior Guide callers to a supported follow-up for the specific record, or state that views only support selected operations. Exporting the complete retained bundle is an existing recovery path. Separately consider whether a bounded incoming-reference view is justified; this report does not assume every Evidence operation needs a view. ### Impact and scope An agent following the advertised summary handoff encounters a nonretryable dead end for this xrefs Evidence. A complete bundle export remains available. One compact-profile test on one host and one operation; other records, autonomous agent behavior, and prevalence are unverified. ### REA version `7f344af1aa0a78fd4e331dbbc9c30d38e4cfb796` (#8509). ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.988. ### Target and artifact context Owned static arm64 Mach-O executable, SHA-256 `3d39bb659d0ec6fdc907ef9ea3d88c2f59fa1b3b870a6f743f518c227c3b18af`, unchanged and unexecuted. ### Interface MCP ### Earliest failure stage Tool description and cross-tool discovery guidance; the explicit unsupported-target error correctly reflects current view support. ### Relevant output or evidence `get_evidence_bundle`: `matching_records: 1`, operation `xrefs`, `retention: "complete-record"`. Both follow-up view requests: `unsupported_target`, `retryable: false`. The tool description says to use a discovered ID with `inspect_analysis_view` without specifying the parent-operation restriction. ### Typed outcome or recovery expected Clear supported-operation guidance and a usable route for a discovered record. Consider how to identify compatible views and retrieve selected source facts without materializing every record, while retaining complete Evidence and honest coverage. ### Analysis or suspected cause Source inspection: the catalog description gives unqualified guidance; `inspect_analysis_view` checks parent-operation support and correctly refuses xrefs. The documentation in `docs/mcp-contracts.md` repeats the unqualified guidance. This does not establish that xrefs must become a view-supported operation. ### Additional context Related: #8348 (making incoming reference observations actionable) and #8510 (stored-pointer omission). @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

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

bsakaguchi referenced this issue

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

[PR #6778] fix(javascript): keep unisolated program-var route values unknown #7411