morluto/rea

Fork 0

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

[GH-ISSUE #8655] [Design] Recover historical Evidence from an incompatible analysis snapshot #7499

New issue

Open

opened 2026-11-03 00:30:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 00:30:16 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

How should an agent recover historical Evidence from a valid analysis snapshot that cannot be reopened under the current provider profile, without requiring the original provider or treating old observations as fresh analysis?

Context and evidence

On draft #8651 with real Ghidra 12.1.4 and stdio MCP on macOS arm64, an older Ghidra snapshot failed open_binary with a typed profile mismatch, as intended. The caller still had the original snapshot file and needed its historical records.

In fresh target-free MCP sessions using compact and full profiles:

import_evidence_bundle({path: <snapshot>}) rejected the valid snapshot as a malformed Evidence bundle and advised supplying an unmodified bundle or recreating observations.
inspect_analysis_view using source.kind=evidence-file and the snapshot path rejected it as wrong-kind, advising repair or recreation.
Manually copying the snapshot's evidence_bundle object to a separate JSON file and importing that file succeeded and preserved the historical Evidence record exactly. The source snapshot and extracted bundle digests were unchanged. The existing native guide describes this manual extraction; it is not an REA snapshot-extraction command.

This is an agent-recovery opportunity, not evidence of lost records or invalid snapshot contents. No autonomous-agent behavior, large files, malformed snapshots, or other providers were tested.

Expected interaction with targets

Read an explicitly selected local snapshot or bundle; optionally write an explicitly selected new bundle. No target execution, provider launch, or mutation of the original snapshot is required by the question.

Boundary details (optional)

Keep snapshot replay admission separate from historical Evidence import. Validate the selected format and authenticated Evidence identities, preserve source data and unknowns, bound parsing and retention, avoid overwriting files without caller choice, and keep errors actionable. Malformed snapshots and partially valid embedded bundles need an explicit contract; do not silently turn invalid snapshots into trusted observations.

Options and tradeoffs

Compare an explicit snapshot-to-Evidence operation, admitting validated snapshot containers at an existing Evidence source boundary, or improving the mismatch recovery with a concrete manual extraction command. Preserve the distinction between extracting history and replaying provider analyses. Do not add a tool solely to expose the snapshot format.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise profile mismatch, recovery in a target-free fresh session, original file unchanged, schema-valid compact/full responses, and exact Evidence/Unknown identity across export/import. Check malformed and oversized snapshots, partial failures, cancellation, cleanup, and file publication before integration. Decide whether validating the full snapshot or only its embedded bundle is required and how to report incomplete data.

References

Related: #8336 and #8651 (profile change that exposed the recovery question), #8380 (historical Evidence versus live Ghidra state). Existing manual recovery guidance: docs/native-investigation.md, instruction-flow section.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Container validation and embedded-history control

Using the old real-Ghidra snapshot from the profile-mismatch control, I changed one digit of a provider entry's query_id in a local copy. REA's parseAnalysisSnapshot rejected the copy with Analysis snapshot query identifier does not match; parsing its unchanged embedded Evidence bundle separately succeeded and returned the same three records and zero unknowns as the valid snapshot. The original snapshot SHA-256 7d5efad01a1fed3725309dc36ed65aaccb46f84b514a5137567eb61283ba3472 was unchanged. This is a local domain-parser control, not a public-tool implementation or a claim that other damage can be recovered.

Source inspection: import_evidence_bundle authenticates an Evidence bundle via the existing bounded JSON reader and payload validation. inspect_analysis_view selects a record from an authenticated Evidence file or bundle. parseAnalysisSnapshot additionally validates snapshot entries and bindings before returning the snapshot. Consequently, blindly selecting an evidence_bundle member from any JSON object would have different semantics from accepting a fully valid snapshot. If REA offers partial-container recovery, it must state that distinction and preserve the container validation failure rather than imply a valid snapshot. Large files, cancellation, and mixed failures remain untested; the separate Unknown-history control below covers one two-revision case.

Unknown-history extraction control

On #8651 head d2ab1b852, real Kuna 1.988 stdio MCP analyzed the unexecuted x86-64 ELF from #8336 and returned a value trace with an explicit unavailable-def-use unknown. I recorded a separate analyst Unknown supported by the trace, then withdrew it in a second revision and saved a snapshot. In both compact and full profiles, manually extracting the snapshot's evidence_bundle and importing it in a fresh target-free session preserved all three recorded Evidence records and both Unknown revisions exactly; list_unknowns found the same identity. Successful outputs validated against their advertised schemas. The source target and snapshot digests were unchanged. This tests manual extraction of one two-revision history, not a native snapshot recovery implementation, unrelated target histories, or general migration.

Originally created by @morluto on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8655 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed How should an agent recover historical Evidence from a valid analysis snapshot that cannot be reopened under the current provider profile, without requiring the original provider or treating old observations as fresh analysis? ### Context and evidence On draft #8651 with real Ghidra 12.1.4 and stdio MCP on macOS arm64, an older Ghidra snapshot failed `open_binary` with a typed profile mismatch, as intended. The caller still had the original snapshot file and needed its historical records. In fresh target-free MCP sessions using compact and full profiles: - `import_evidence_bundle({path: <snapshot>})` rejected the valid snapshot as a malformed Evidence bundle and advised supplying an unmodified bundle or recreating observations. - `inspect_analysis_view` using `source.kind=evidence-file` and the snapshot path rejected it as `wrong-kind`, advising repair or recreation. - Manually copying the snapshot's `evidence_bundle` object to a separate JSON file and importing that file succeeded and preserved the historical Evidence record exactly. The source snapshot and extracted bundle digests were unchanged. The existing native guide describes this manual extraction; it is not an REA snapshot-extraction command. This is an agent-recovery opportunity, not evidence of lost records or invalid snapshot contents. No autonomous-agent behavior, large files, malformed snapshots, or other providers were tested. ### Expected interaction with targets Read an explicitly selected local snapshot or bundle; optionally write an explicitly selected new bundle. No target execution, provider launch, or mutation of the original snapshot is required by the question. ### Boundary details (optional) Keep snapshot replay admission separate from historical Evidence import. Validate the selected format and authenticated Evidence identities, preserve source data and unknowns, bound parsing and retention, avoid overwriting files without caller choice, and keep errors actionable. Malformed snapshots and partially valid embedded bundles need an explicit contract; do not silently turn invalid snapshots into trusted observations. ### Options and tradeoffs Compare an explicit snapshot-to-Evidence operation, admitting validated snapshot containers at an existing Evidence source boundary, or improving the mismatch recovery with a concrete manual extraction command. Preserve the distinction between extracting history and replaying provider analyses. Do not add a tool solely to expose the snapshot format. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise profile mismatch, recovery in a target-free fresh session, original file unchanged, schema-valid compact/full responses, and exact Evidence/Unknown identity across export/import. Check malformed and oversized snapshots, partial failures, cancellation, cleanup, and file publication before integration. Decide whether validating the full snapshot or only its embedded bundle is required and how to report incomplete data. ### References Related: #8336 and #8651 (profile change that exposed the recovery question), #8380 (historical Evidence versus live Ghidra state). Existing manual recovery guidance: `docs/native-investigation.md`, instruction-flow section. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Container validation and embedded-history control Using the old real-Ghidra snapshot from the profile-mismatch control, I changed one digit of a provider entry's `query_id` in a local copy. REA's `parseAnalysisSnapshot` rejected the copy with `Analysis snapshot query identifier does not match`; parsing its unchanged embedded Evidence bundle separately succeeded and returned the same three records and zero unknowns as the valid snapshot. The original snapshot SHA-256 `7d5efad01a1fed3725309dc36ed65aaccb46f84b514a5137567eb61283ba3472` was unchanged. This is a local domain-parser control, not a public-tool implementation or a claim that other damage can be recovered. Source inspection: `import_evidence_bundle` authenticates an Evidence bundle via the existing bounded JSON reader and payload validation. `inspect_analysis_view` selects a record from an authenticated Evidence file or bundle. `parseAnalysisSnapshot` additionally validates snapshot entries and bindings before returning the snapshot. Consequently, blindly selecting an `evidence_bundle` member from any JSON object would have different semantics from accepting a fully valid snapshot. If REA offers partial-container recovery, it must state that distinction and preserve the container validation failure rather than imply a valid snapshot. Large files, cancellation, and mixed failures remain untested; the separate Unknown-history control below covers one two-revision case. ### Unknown-history extraction control On #8651 head `d2ab1b852`, real Kuna 1.988 stdio MCP analyzed the unexecuted x86-64 ELF from #8336 and returned a value trace with an explicit unavailable-def-use unknown. I recorded a separate analyst Unknown supported by the trace, then withdrew it in a second revision and saved a snapshot. In both compact and full profiles, manually extracting the snapshot's `evidence_bundle` and importing it in a fresh target-free session preserved all three recorded Evidence records and both Unknown revisions exactly; `list_unknowns` found the same identity. Successful outputs validated against their advertised schemas. The source target and snapshot digests were unchanged. This tests manual extraction of one two-revision history, not a native snapshot recovery implementation, unrelated target histories, or general migration.

bsakaguchi added the

enhancement

triage

labels

2026-11-03 00:30:16 +00:00

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

No description provided.

Rows
Columns