morluto/rea

Fork 0

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

[GH-ISSUE #8243] [Design] Reuse the refreshed annotation dossier as a function observation #6513

New issue

Open

opened 2026-11-01 21:11:48 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-11-01 21:11:48 +00:00

Owner

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

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

Should the refreshed dossier already returned by annotate_native_function be usable as an authenticated function observation in downstream workflows, particularly compare_functions, without another provider analysis before the Ghidra session closes?

Context and evidence

On macOS arm64, REA 53a4ab78451a0654e9c3beb3d43a5e371a288fcc, Ghidra 12.1.4 and a self-built, unexecuted Mach-O, the CLI annotation returned complete Evidence with a refreshed dossier and correctly disclosed that its session edit would be discarded. Saving the JSON preserves that observation. In a separate MCP server, I supplied that original CLI Evidence inline as the right side of compare_functions and an actual analyze_function retained reference on the left. The call rejected it: Function analysis requires analyze_function Evidence ... the right Evidence has operation annotate_native_function. The same rejection occurred with a retained annotation Evidence record made within the MCP session.

The current workaround works while the MCP session is live: run analyze_function again after the edit and compare the two retained dossier references. This succeeded; it reported changed identity, comments and exact pseudocode, with unchanged assembly for this sample. The result also reported a name-based mismatch for the same entry, separately tracked in #8213. Initial calls with two complete records inline exceeded the default 1024-element MCP allowance; retained references avoided that limit (related #8214). The original executable digest stayed unchanged.

Once the one-shot CLI command finishes, reanalysis in a new session observes the original metadata, so it cannot recover the edited state that was already returned. This does not imply that the persisted JSON is missing, that a session edit is durable, or that annotation Evidence should be silently relabeled as analyze_function.

Expected interaction with targets

Read existing files or captured data; write or change files/configuration only if an operator elects to save output. The demonstrated annotation changed the existing ephemeral session database and did not modify executable bytes. No target execution.

Boundary details

Keep the original authenticated annotation operation, edit effects, provider context and evidence links; any projection must authenticate its source and preserve limitations. A portable observation is distinct from an editable project, replayable annotations or runtime behavior. Do not infer behavioral change from changed labels or provider text.

Options and tradeoffs

Consider an explicitly typed projection/derived function observation or narrowly allowing annotated dossiers as inputs where their provenance can be retained. Alternatively, explain the current MCP reanalysis workaround before session close and accept that saved one-shot annotation results cannot enter these workflows. Assess contract and Evidence identity changes before choosing.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

A controlled comparison of a pre-edit function to the saved annotation result should either succeed with both source identities and limitations intact or clearly document the supported alternative. Check tampered records, missing dossier facets and downstream consumers; no such changes have been implemented or tested here.

References

#8242 covers CLI help; #6405 covers annotation replay; #8165 covers checkpoints. Comparison contract and function Evidence parser explicitly require analyze_function.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8243 ### 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 Should the refreshed dossier already returned by `annotate_native_function` be usable as an authenticated function observation in downstream workflows, particularly `compare_functions`, without another provider analysis before the Ghidra session closes? ### Context and evidence On macOS arm64, REA `53a4ab78451a0654e9c3beb3d43a5e371a288fcc`, Ghidra 12.1.4 and a self-built, unexecuted Mach-O, the CLI annotation returned complete Evidence with a refreshed dossier and correctly disclosed that its session edit would be discarded. Saving the JSON preserves that observation. In a separate MCP server, I supplied that original CLI Evidence inline as the right side of `compare_functions` and an actual `analyze_function` retained reference on the left. The call rejected it: `Function analysis requires analyze_function Evidence ... the right Evidence has operation annotate_native_function`. The same rejection occurred with a retained annotation Evidence record made within the MCP session. The current workaround works while the MCP session is live: run `analyze_function` again after the edit and compare the two retained dossier references. This succeeded; it reported changed identity, comments and exact pseudocode, with unchanged assembly for this sample. The result also reported a name-based mismatch for the same entry, separately tracked in #8213. Initial calls with two complete records inline exceeded the default 1024-element MCP allowance; retained references avoided that limit (related #8214). The original executable digest stayed unchanged. Once the one-shot CLI command finishes, reanalysis in a new session observes the original metadata, so it cannot recover the edited state that was already returned. This does not imply that the persisted JSON is missing, that a session edit is durable, or that annotation Evidence should be silently relabeled as `analyze_function`. ### Expected interaction with targets Read existing files or captured data; write or change files/configuration only if an operator elects to save output. The demonstrated annotation changed the existing ephemeral session database and did not modify executable bytes. No target execution. ### Boundary details Keep the original authenticated annotation operation, edit effects, provider context and evidence links; any projection must authenticate its source and preserve limitations. A portable observation is distinct from an editable project, replayable annotations or runtime behavior. Do not infer behavioral change from changed labels or provider text. ### Options and tradeoffs Consider an explicitly typed projection/derived function observation or narrowly allowing annotated dossiers as inputs where their provenance can be retained. Alternatively, explain the current MCP reanalysis workaround before session close and accept that saved one-shot annotation results cannot enter these workflows. Assess contract and Evidence identity changes before choosing. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions A controlled comparison of a pre-edit function to the saved annotation result should either succeed with both source identities and limitations intact or clearly document the supported alternative. Check tampered records, missing dossier facets and downstream consumers; no such changes have been implemented or tested here. ### References [#8242](https://github.com/morluto/rea/issues/8242) covers CLI help; [#6405](https://github.com/morluto/rea/issues/6405) covers annotation replay; [#8165](https://github.com/morluto/rea/issues/8165) covers checkpoints. [Comparison contract](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/src/contracts/sessionToolContracts.ts) and [function Evidence parser](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/src/domain/functionDossierEvidence.ts) explicitly require `analyze_function`.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:11:48 +00:00

bsakaguchi commented

2026-11-01 21:11:48 +00:00

Author

Owner

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

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:48 +00:00

Author

Owner

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

Additional offline handoff control on REA main e6d061897, macOS arm64, real Ghidra 12.1.4. CLI annotate-native-function saved complete JSON containing the edited name cli_view_probe, its comment and refreshed pseudocode; the Evidence limitation accurately states that the Ghidra session edit is discarded on CLI exit. A fresh CLI function call using that edited name failed, and a call using the original _adjust succeeded. The target digest remained unchanged.

The saved annotation JSON remains directly readable, but the existing inspect_analysis_view summary projector does not accept its annotate_native_function operation. I tested both CLI with the complete inline Evidence and target-free MCP with an evidence-file reference: both returned unsupported_target naming the unsupported operation. As a positive control, the same CLI and MCP view requests against the fresh analyze_function Evidence succeeded and returned _adjust's summary. No provider was needed during either offline view request.

This extends the handoff question beyond compare_functions: an agent can read the full saved annotation JSON, but cannot use the existing bounded function view to select its dossier facets after the one-shot session closes. Any supported projection should authenticate the original annotation Evidence and retain its operation, edit effects and session-lifetime caveat; it must not suggest the project or edit can be reopened. This is one fixture and does not establish a model-selection failure rate.

@morluto commented on GitHub (Oct 31, 2026): Additional offline handoff control on REA main `e6d061897`, macOS arm64, real Ghidra 12.1.4. CLI `annotate-native-function` saved complete JSON containing the edited name `cli_view_probe`, its comment and refreshed pseudocode; the Evidence limitation accurately states that the Ghidra session edit is discarded on CLI exit. A fresh CLI `function` call using that edited name failed, and a call using the original `_adjust` succeeded. The target digest remained unchanged. The saved annotation JSON remains directly readable, but the existing `inspect_analysis_view` summary projector does not accept its `annotate_native_function` operation. I tested both CLI with the complete inline Evidence and target-free MCP with an `evidence-file` reference: both returned `unsupported_target` naming the unsupported operation. As a positive control, the same CLI and MCP view requests against the fresh `analyze_function` Evidence succeeded and returned `_adjust`'s summary. No provider was needed during either offline view request. This extends the handoff question beyond `compare_functions`: an agent can read the full saved annotation JSON, but cannot use the existing bounded function view to select its dossier facets after the one-shot session closes. Any supported projection should authenticate the original annotation Evidence and retain its operation, edit effects and session-lifetime caveat; it must not suggest the project or edit can be reopened. This is one fixture and does not establish a model-selection failure rate.

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

No description provided.

Rows
Columns