morluto/rea

Fork 0

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

[GH-ISSUE #8307] [Design] Retrieve selected historical annotation Evidence without transferring the whole bundle #6537

New issue

Closed

opened 2026-11-01 21:12:02 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

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

Originally assigned to: @kaoru0822-kitauji on GitHub.

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 can an analyst retrieve a specific retained annotation's readback and target identity after a session transition without transferring the complete Evidence bundle, while keeping historical records distinct from the active database?

Context and evidence

On REA b43c329df779708e43ae297f498a844e45d9c923, with real Ghidra 12.1.4 and two self-built arm64 Mach-O files, I renamed a function and added a comment in target A's ephemeral session, switched to target B, and then reopened A. The original name returned; the edit survived as historical annotate_native_function Evidence. Target hashes remained unchanged and neither target was executed. The transition/lifetime question is already tracked in #8289.

While B was active, get_evidence_bundle({detail:"summary",filters:{operation:"annotate_native_function"}}) found the record for A, including its exact ID and A's digest. The summary omitted the annotation readback. inspect_analysis_view on that exact ID returned unsupported_target because annotation Evidence is not an eligible view parent. get_evidence_bundle({detail:"complete"}) did return the original name, comment, target identity and other records together. After exporting and importing the bundle into a fresh target-free server, filtering the summary by the ID again found the record; requesting detail:"complete" with that filter returned invalid_request, and the unsupported view result repeated. The unfiltered complete bundle returned four records, including the desired annotation. Its full SDK reply serialized to 91,421 bytes in this one test; this includes the SDK's text and structured representations and is not a model-token or latency measurement.

Existing workarounds are to retain the original annotation response, request the entire complete bundle, or export and inspect that bundle locally. The result is historical readback, not an editable Ghidra checkpoint or proof that the edit is still active. This test does not establish that other tools cannot retrieve a record, or that typical bundles exceed a response budget.

Expected interaction with targets

Read existing retained or explicitly supplied Evidence; no target execution, implicit provider restart, project mutation, or automatic annotation replay is proposed.

Boundary details (optional)

Preserve the exact Evidence ID, subject digest, provider/profile, name/comment readback, operation and historical semantics. Do not silently turn selected records into an authenticated complete bundle or drop required Evidence closure. Avoid presenting an old annotation as current live state.

Options and tradeoffs

Compare a bounded annotation readback view with a general exact retained-Evidence record retrieval contract, or leave the existing full-bundle/local-file route if it is adequate. Consider large individual dossiers, pagination or field selection, authentication and output budgets; do not assume one tool or full inline record is the right answer. This complements #6405's explicit annotation export/replay design and #8293's Evidence-input resolution proposal rather than defining either.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise active versus retired sessions, multiple target digests, multiple annotation revisions, explicit clears and failed edits, plus retained and imported sources. Verify correct identity, complete-source availability and honest historical labeling. Measure representative agent tasks before claiming token or time savings. No autonomous-agent trial or large-bundle performance measurement was run here.

References

#8289, #6405, #8293; the bundle discovery contract says filters apply only to summary delivery.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8307 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the 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 can an analyst retrieve a specific retained annotation's readback and target identity after a session transition without transferring the complete Evidence bundle, while keeping historical records distinct from the active database? ### Context and evidence On REA `b43c329df779708e43ae297f498a844e45d9c923`, with real Ghidra 12.1.4 and two self-built arm64 Mach-O files, I renamed a function and added a comment in target A's ephemeral session, switched to target B, and then reopened A. The original name returned; the edit survived as historical `annotate_native_function` Evidence. Target hashes remained unchanged and neither target was executed. The transition/lifetime question is already tracked in #8289. While B was active, `get_evidence_bundle({detail:"summary",filters:{operation:"annotate_native_function"}})` found the record for A, including its exact ID and A's digest. The summary omitted the annotation readback. `inspect_analysis_view` on that exact ID returned `unsupported_target` because annotation Evidence is not an eligible view parent. `get_evidence_bundle({detail:"complete"})` did return the original name, comment, target identity and other records together. After exporting and importing the bundle into a fresh target-free server, filtering the summary by the ID again found the record; requesting `detail:"complete"` with that filter returned `invalid_request`, and the unsupported view result repeated. The unfiltered complete bundle returned four records, including the desired annotation. Its full SDK reply serialized to 91,421 bytes in this one test; this includes the SDK's text and structured representations and is not a model-token or latency measurement. Existing workarounds are to retain the original annotation response, request the entire complete bundle, or export and inspect that bundle locally. The result is historical readback, not an editable Ghidra checkpoint or proof that the edit is still active. This test does not establish that other tools cannot retrieve a record, or that typical bundles exceed a response budget. ### Expected interaction with targets Read existing retained or explicitly supplied Evidence; no target execution, implicit provider restart, project mutation, or automatic annotation replay is proposed. ### Boundary details (optional) Preserve the exact Evidence ID, subject digest, provider/profile, name/comment readback, operation and historical semantics. Do not silently turn selected records into an authenticated complete bundle or drop required Evidence closure. Avoid presenting an old annotation as current live state. ### Options and tradeoffs Compare a bounded annotation readback view with a general exact retained-Evidence record retrieval contract, or leave the existing full-bundle/local-file route if it is adequate. Consider large individual dossiers, pagination or field selection, authentication and output budgets; do not assume one tool or full inline record is the right answer. This complements #6405's explicit annotation export/replay design and #8293's Evidence-input resolution proposal rather than defining either. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise active versus retired sessions, multiple target digests, multiple annotation revisions, explicit clears and failed edits, plus retained and imported sources. Verify correct identity, complete-source availability and honest historical labeling. Measure representative agent tasks before claiming token or time savings. No autonomous-agent trial or large-bundle performance measurement was run here. ### References #8289, #6405, #8293; the [bundle discovery contract](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/contracts/sessionToolContracts.ts) says filters apply only to summary delivery. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi

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

closed this issue
added the
enhancement

triage
labels

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A separate experimental, unmerged batch-provenance change in #8350 creates exact retained procedure_pseudo_code source records and links them to successful batch items. On a real Kuna Rust fixture, the source records distinguish single-function from project-export pseudocode for the same entry. After importing the bundle into a fresh server, exact-ID summaries found both records, but did not include their raw source kind; detail: complete plus an ID filter returned invalid_request, and inspect_analysis_view on each pseudocode record returned unsupported_target. The unfiltered complete bundle contained both exact source records. The bundle hash was unchanged.

This is a test of the existing retrieval surface using a prototype producer, not a claim that current batch_decompile already retains these sources. It extends the question beyond annotations: if future workflows return source Evidence IDs, a bounded way to inspect the relevant historical source facts may be needed for those IDs to be useful without transferring a whole bundle. The memory/duplication and cancellation limitations of the prototype are documented in #8350.

@morluto commented on GitHub (Oct 31, 2026): A separate **experimental, unmerged** batch-provenance change in #8350 creates exact retained `procedure_pseudo_code` source records and links them to successful batch items. On a real Kuna Rust fixture, the source records distinguish single-function from project-export pseudocode for the same entry. After importing the bundle into a fresh server, exact-ID summaries found both records, but did not include their raw source kind; `detail: complete` plus an ID filter returned `invalid_request`, and `inspect_analysis_view` on each pseudocode record returned `unsupported_target`. The unfiltered complete bundle contained both exact source records. The bundle hash was unchanged. This is a test of the existing retrieval surface using a prototype producer, not a claim that current `batch_decompile` already retains these sources. It extends the question beyond annotations: if future workflows return source Evidence IDs, a bounded way to inspect the relevant historical source facts may be needed for those IDs to be useful without transferring a whole bundle. The memory/duplication and cancellation limitations of the prototype are documented in #8350.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A related feature-trace handoff reaches the same retrieval boundary, using the unmerged #8368 branch and an unverified Kuna source build (not a verified-release upgrade claim):

The branch returned a string match, an incoming reference and an explicitly unavailable owner. Its Evidence was exported, then imported into a fresh MCP server with no target open. The unfiltered complete bundle contained a trace record structurally identical to the original, including the reference and residual unknown.
get_evidence_bundle({detail:"summary",filters:{evidence_id:<trace ID>}}) found exactly one record and reported retention:"complete-record", but the summary did not contain the match, reference or unavailable-owner outcome.
inspect_analysis_view({source:{kind:"retained-evidence",evidence_id:<trace ID>},view:{kind:"summary"}}) returned unsupported_target because trace_feature is not a supported view parent. get_evidence_bundle with the same filter and detail:"complete" returned invalid_request, explaining that filters require summary. An unfiltered complete bundle was a working fallback and contained six records in this test.

This demonstrates preservation, but not targeted retrieval, of this particular partial trace after import. get_evidence_bundle's catalog description suggests using a discovered ID with inspect_analysis_view; this trace is a concrete exception. It does not establish a typical bundle size, an agent failure rate, or the right general retrieval design. Calls used the advertised full MCP schemas; the only successful targeted operation was summary discovery. Related to the existing annotation case in this issue and feature-trace coverage #8184. The base d54a4661 errors before producing this partial outcome, so this is evidence about the PR's new result and the shared current retrieval contracts, not a claim that main already returns this variant.

@morluto commented on GitHub (Oct 31, 2026): A related **feature-trace** handoff reaches the same retrieval boundary, using the unmerged #8368 branch and an unverified Kuna source build (not a verified-release upgrade claim): 1. The branch returned a string match, an incoming reference and an explicitly unavailable owner. Its Evidence was exported, then imported into a fresh MCP server with no target open. The unfiltered complete bundle contained a trace record structurally identical to the original, including the reference and residual unknown. 2. `get_evidence_bundle({detail:"summary",filters:{evidence_id:<trace ID>}})` found exactly one record and reported `retention:"complete-record"`, but the summary did not contain the match, reference or unavailable-owner outcome. 3. `inspect_analysis_view({source:{kind:"retained-evidence",evidence_id:<trace ID>},view:{kind:"summary"}})` returned `unsupported_target` because `trace_feature` is not a supported view parent. `get_evidence_bundle` with the same filter and `detail:"complete"` returned `invalid_request`, explaining that filters require summary. An unfiltered complete bundle was a working fallback and contained six records in this test. This demonstrates preservation, but not targeted retrieval, of this particular partial trace after import. `get_evidence_bundle`'s catalog description suggests using a discovered ID with `inspect_analysis_view`; this trace is a concrete exception. It does not establish a typical bundle size, an agent failure rate, or the right general retrieval design. Calls used the advertised full MCP schemas; the only successful targeted operation was summary discovery. Related to the existing annotation case in this issue and feature-trace coverage #8184. The base `d54a4661` errors before producing this partial outcome, so this is evidence about the PR's new result and the shared current retrieval contracts, not a claim that main already returns this variant.

bsakaguchi commented

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

Author

Owner

@kaoru0822-kitauji commented on GitHub (Nov 1, 2026):

Proposal (source-derived on aa48d494e; I'll implement it unless someone objects). I prefer one general contract over per-operation views. The annotation, pseudocode-source and native-trace cases above all hit the same boundary, and inspectEvidenceBundle is already the single owner shared by MCP get_evidence_bundle and CLI inspect-evidence-bundle.

detail: "records" selects complete retained records with the same exact filters as summary, plus top-level offset/limit (default 0/8, retained ledger order):

{ "kind": "evidence-record-selection", "filters": {…}, "total_retained_records": 4, "matching_records": 1,
  "offset": 0, "limit": 8, "next_offset": null,
  "records": [ /* complete authenticated Evidence, unchanged IDs */ ],
  "missing_evidence_links": [ /* direct evidence_links of the selected records that this session/bundle does not retain */ ],
  "limitations": [ "Selected records are retained historical observations; they do not establish current live provider or database state.", … ] }

Not a bundle: there are no manifests or unknown revisions, so it cannot be imported as a bundle. complete keeps returning the canonical bundle, and complete + filters stays invalid_request. offset/limit are rejected outside records.
Historical and identity-preserving: each record keeps its own ID, subject digest, provider/profile and readback, and the provider is never consulted. That covers a retired session's annotation after a target switch, and imported records.
Closure is explicit: missing_evidence_links reports direct links only, with no traversal, so a selected record whose sources are absent says so instead of implying closure.
Bounded delivery: an oversized selection's guidance says to reduce limit or select one evidence_id. A single record larger than one MCP frame still needs export_evidence_bundle (or inspect_analysis_view where that parent supports views).

Out of scope: residual-unknown selection (list_unknowns already pages it), multi-ID batch filters, and annotation replay (#6405).

@kaoru0822-kitauji commented on GitHub (Nov 1, 2026): Proposal (source-derived on `aa48d494e`; I'll implement it unless someone objects). I prefer one general contract over per-operation views. The annotation, pseudocode-source and native-trace cases above all hit the same boundary, and `inspectEvidenceBundle` is already the single owner shared by MCP `get_evidence_bundle` and CLI `inspect-evidence-bundle`. **`detail: "records"`** selects complete retained records with the same exact filters as `summary`, plus top-level `offset`/`limit` (default 0/8, retained ledger order): ```json { "kind": "evidence-record-selection", "filters": {…}, "total_retained_records": 4, "matching_records": 1, "offset": 0, "limit": 8, "next_offset": null, "records": [ /* complete authenticated Evidence, unchanged IDs */ ], "missing_evidence_links": [ /* direct evidence_links of the selected records that this session/bundle does not retain */ ], "limitations": [ "Selected records are retained historical observations; they do not establish current live provider or database state.", … ] } ``` - **Not a bundle:** there are no manifests or unknown revisions, so it cannot be imported as a bundle. `complete` keeps returning the canonical bundle, and `complete` + filters stays `invalid_request`. `offset`/`limit` are rejected outside `records`. - **Historical and identity-preserving:** each record keeps its own ID, subject digest, provider/profile and readback, and the provider is never consulted. That covers a retired session's annotation after a target switch, and imported records. - **Closure is explicit:** `missing_evidence_links` reports direct links only, with no traversal, so a selected record whose sources are absent says so instead of implying closure. - **Bounded delivery:** an oversized selection's guidance says to reduce `limit` or select one `evidence_id`. A single record larger than one MCP frame still needs `export_evidence_bundle` (or `inspect_analysis_view` where that parent supports views). Out of scope: residual-unknown selection (`list_unknowns` already pages it), multi-ID batch filters, and annotation replay (#6405).

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

No description provided.

Rows
Columns