morluto/rea

Fork 0

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

[GH-ISSUE #8409] [Bug] Unsupported Evidence view suggests changing target format #6591

New issue

Open

opened 2026-11-01 21:12:29 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

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 / Evidence recovery

Observed behavior

inspect_analysis_view correctly rejects an unsupported parent Evidence operation, but the structured remediation.action advises selecting a different target format. The failure is about the parent Evidence operation, and the same result occurs in a target-free server after importing its bundle.

Reproduction

On REA main 6e9ee97a, real Kuna 1.986, and a source-owned arm64 Mach-O:

Open the target and call trace_feature for a function name; retain its returned Evidence ID.
Call inspect_analysis_view with source: {kind: "retained-evidence", evidence_id: <trace ID>} and view: {kind: "summary"}.
Export the Evidence bundle, import it in a fresh target-free server, and repeat the same view request.

Both live and imported requests returned unsupported_target; the message and details.reason correctly identify trace_feature as unsupported, but remediation.action was:

Select a target supported by this operation or choose an operation supporting the reported target format.

A retained analyze_function record from the same session successfully produced a summary view before and after import. The original trace's normalized result and limitations matched after import. Both compact and full advertised MCP input-schema profiles with full output-schema validation were exercised. The target was not executed or changed.

Expected behavior

Keep the typed unsupported result and name a recovery appropriate to the supplied Evidence: inspect a compatible parent/view if that is the task, or read the original complete Evidence or bundle. For session-retained records, get_evidence_bundle complete delivery or export_evidence_bundle are existing alternatives; complete MCP delivery can exceed its response limit. Do not imply that importing a different target makes trace_feature viewable.

Impact and scope

An agent reading the machine-readable remediation can take an irrelevant action even though the diagnostic reason is accurate. This is a scripted workflow, not a measured autonomous-agent failure rate. Only the two schema profiles, one host, one provider, and the trace_feature parent were reproduced. Other inspect_analysis_view unsupported cases were not exercised in this report.

REA version

6e9ee97a69cb16c7150d8b550e705cba055ee4f0.

Runtime and platform

macOS arm64, Node 24.22.1, MCP TypeScript SDK 2.3.1, Kuna 1.986.

Target and artifact context

Source-owned arm64 Mach-O dylib, SHA-256 88599b046794dea3a1035049f01d0ecebc683fd34f4dc3367e63b9a0ba89e784; same digest before and after. No target execution.

Interface

MCP stdio.

Earliest failure stage

Shared analysis-view error construction and projection; no provider failure is required.

Relevant output or evidence

The original trace was recovered from the exported/imported bundle; a function dossier view remained usable. #8373 describes the broader missing trace pagination. PR #8377 qualifies the catalog's discovery guidance, but this independent structured error remains unchanged.

Typed outcome or recovery expected

Keep unsupported_target nonretryable with accurate operation/parent details; give parent/view or original-Evidence recovery in remediation.action, with wording appropriate to retained, inline, and file sources.

Analysis or suspected cause

Source-derived: unsupportedParent creates AnalysisUnsupportedTargetError without an operation-specific remediation; analysisErrorPresentation therefore uses its target-format fallback. Other analysis-view unsupported producers also construct that error; their applicability and appropriate recovery should be checked rather than assuming this one sentence fits all cases.

Additional context

Maintainers: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8409 ### 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 / Evidence recovery ### Observed behavior `inspect_analysis_view` correctly rejects an unsupported parent Evidence operation, but the structured `remediation.action` advises selecting a different target format. The failure is about the parent Evidence operation, and the same result occurs in a target-free server after importing its bundle. ### Reproduction On REA main `6e9ee97a`, real Kuna 1.986, and a source-owned arm64 Mach-O: 1. Open the target and call `trace_feature` for a function name; retain its returned Evidence ID. 2. Call `inspect_analysis_view` with `source: {kind: "retained-evidence", evidence_id: <trace ID>}` and `view: {kind: "summary"}`. 3. Export the Evidence bundle, import it in a fresh target-free server, and repeat the same view request. Both live and imported requests returned `unsupported_target`; the message and `details.reason` correctly identify `trace_feature` as unsupported, but `remediation.action` was: > Select a target supported by this operation or choose an operation supporting the reported target format. A retained `analyze_function` record from the same session successfully produced a summary view before and after import. The original trace's normalized result and limitations matched after import. Both compact and full advertised MCP input-schema profiles with full output-schema validation were exercised. The target was not executed or changed. ### Expected behavior Keep the typed unsupported result and name a recovery appropriate to the supplied Evidence: inspect a compatible parent/view if that is the task, or read the original complete Evidence or bundle. For session-retained records, `get_evidence_bundle` complete delivery or `export_evidence_bundle` are existing alternatives; complete MCP delivery can exceed its response limit. Do not imply that importing a different target makes `trace_feature` viewable. ### Impact and scope An agent reading the machine-readable remediation can take an irrelevant action even though the diagnostic reason is accurate. This is a scripted workflow, not a measured autonomous-agent failure rate. Only the two schema profiles, one host, one provider, and the `trace_feature` parent were reproduced. Other `inspect_analysis_view` unsupported cases were not exercised in this report. ### REA version `6e9ee97a69cb16c7150d8b550e705cba055ee4f0`. ### Runtime and platform macOS arm64, Node 24.22.1, MCP TypeScript SDK 2.3.1, Kuna 1.986. ### Target and artifact context Source-owned arm64 Mach-O dylib, SHA-256 `88599b046794dea3a1035049f01d0ecebc683fd34f4dc3367e63b9a0ba89e784`; same digest before and after. No target execution. ### Interface MCP stdio. ### Earliest failure stage Shared analysis-view error construction and projection; no provider failure is required. ### Relevant output or evidence The original trace was recovered from the exported/imported bundle; a function dossier view remained usable. [#8373](https://github.com/morluto/rea/issues/8373) describes the broader missing trace pagination. [PR #8377](https://github.com/morluto/rea/pull/8377) qualifies the catalog's discovery guidance, but this independent structured error remains unchanged. ### Typed outcome or recovery expected Keep `unsupported_target` nonretryable with accurate operation/parent details; give parent/view or original-Evidence recovery in `remediation.action`, with wording appropriate to retained, inline, and file sources. ### Analysis or suspected cause Source-derived: [`unsupportedParent`](https://github.com/morluto/rea/blob/6e9ee97a69cb16c7150d8b550e705cba055ee4f0/src/domain/analysisView/analysisView.ts) creates `AnalysisUnsupportedTargetError` without an operation-specific remediation; [`analysisErrorPresentation`](https://github.com/morluto/rea/blob/6e9ee97a69cb16c7150d8b550e705cba055ee4f0/src/domain/analysisErrorPresentation.ts) therefore uses its target-format fallback. Other analysis-view unsupported producers also construct that error; their applicability and appropriate recovery should be checked rather than assuming this one sentence fits all cases. ### Additional context Maintainers: @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

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

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

A second refusal in the same view workflow has a different recovery. In a real stdio MCP session on macOS arm64, I inspected a source-owned synthetic HAR with one explicitly declared test-only sensitive value. inspect_analysis_view with view: {kind: "api-surface"} refused the resulting capture with unsupported_target, details.reason: "sensitive_values_unretained", and the same generic target-format action. Its capture preview remained usable. A separate ordinary HAR without any declared sensitive value produced the API-surface view successfully. Both inputs remained byte-identical, and the declared test marker did not appear in returned Evidence or the error.

On the local #8412 follow-up, the refusal and reason remain unchanged, but the action explains that sensitivity declarations were not retained and points to a compatible capture or summary view; it does not suggest removing declarations to bypass the check. The same real HAR control passed, and both baseline and updated errors validated against the documented 2020-12 error schema. Two existing MCP boundary cases for environment-state and environment-manifest also failed on the original action and passed with the new one. This is one synthetic HAR workflow, not a browser-capture test or a claim about all sensitivity policies.

A separate native control imported a real Kuna dossier into a target-free server and asked for a Mach-O view. That is a different case: it returned invalid_request with an explicit issue saying analyze_function requires a native or summary view; selecting summary succeeded. It should not be conflated with the unsupported-parent refusal.

@morluto commented on GitHub (Nov 1, 2026): A second refusal in the same view workflow has a different recovery. In a real stdio MCP session on macOS arm64, I inspected a source-owned synthetic HAR with one explicitly declared test-only sensitive value. `inspect_analysis_view` with `view: {kind: "api-surface"}` refused the resulting capture with `unsupported_target`, `details.reason: "sensitive_values_unretained"`, and the same generic target-format action. Its `capture` preview remained usable. A separate ordinary HAR without any declared sensitive value produced the API-surface view successfully. Both inputs remained byte-identical, and the declared test marker did not appear in returned Evidence or the error. On the local #8412 follow-up, the refusal and reason remain unchanged, but the action explains that sensitivity declarations were not retained and points to a compatible capture or summary view; it does not suggest removing declarations to bypass the check. The same real HAR control passed, and both baseline and updated errors validated against the documented 2020-12 error schema. Two existing MCP boundary cases for environment-state and environment-manifest also failed on the original action and passed with the new one. This is one synthetic HAR workflow, not a browser-capture test or a claim about all sensitivity policies. A separate native control imported a real Kuna dossier into a target-free server and asked for a Mach-O view. That is a different case: it returned `invalid_request` with an explicit issue saying `analyze_function` requires a native or summary view; selecting summary succeeded. It should not be conflated with the unsupported-parent refusal.

bsakaguchi referenced this issue

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

[PR #6591] [CLOSED] fix(cli): merge sibling filter paths through the same array slice #7381

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

No description provided.

Rows
Columns