morluto/rea

Fork 0

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

[GH-ISSUE #8355] [Bug] Decompile directory omits source inventory limitations #6560

New issue

Open

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

decompile_all carries limitations of the list_procedures inventory in its returned Evidence, but the generated decompile-index.json and normalized manifest do not retain those inventory-level limitations. An export directory separated from the tool response can therefore lack facts needed to interpret why functions were selected or omitted. This is separate from per-function caveats, which are retained in each record when there is one.

Reproduction

On REA d54a4661, using an owned arm64 Mach-O with three functions, an exported data global, and a Ghidra project imported with -noanalysis:

Select the saved project with REA_GHIDRA_PROJECT_PATH and REA_GHIDRA_PROGRAM_NAME, open its matching binary, and call decompile_all({output_directory:<new>, name:"_evaluate"}).
The returned Evidence says the selected project's original analysis completeness/settings are unknown. Its normalized manifest reports selected:0, excluded:1, written:0. The directory index has zero function records and limitations:[]; there are no function files that could carry the project caveat.
A fresh Ghidra import of the same target with the same filter selected and wrote _evaluate. This verifies the difference between these two inventories, not runtime behavior or universal discovery completeness.
With real Kuna 1.986 on the same target, an unfiltered export wrote three functions. The returned Evidence warned that Kuna's source inventory also contained three entries that REA omitted based on Mach-O regions. The index retained the separate unknown-body-range limitation, but neither its top-level fields nor its function records/files retained that inventory-omission warning.

The selected-project Ghidra and Kuna filtered cases were also run through rea decompile-all ... --format json, with and without --full-output: CLI output retained the respective Evidence warning, while each index lacked it. Counts and directory contents are observations of the provider inventory, not proof that an unmatched function does or does not exist.

Expected behavior

Make the directory's selection/inventory scope and material inventory limitations accessible alongside its index, or provide another explicit, durable link from the directory to the relevant retained Evidence. Preserve the distinction between inventory-level caveats and per-function observations, including an empty selection. Clarify whether a resumed directory represents the current selection or accumulated selections; do not attach a new run's warning to old files as if it produced them.

Impact and scope

An analyst who retains the Evidence response or exports its Evidence bundle still has the caveat; the issue is the standalone generated directory and normalized manifest. The Ghidra nonempty export's function record and file did retain the general unknown-analysis caveat from their own per-function operations. The zero-selection export had no such record. I did not measure an actual agent misinterpretation. One source-owned fixture and one macOS host were tested; broader provider behavior and interrupted/resumed exports are unverified.

REA version

d54a4661da20382ad8456564a08569fdd24131c5.

Runtime and platform

Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21; Kuna 1.986; TypeScript MCP SDK 2.3.1.

Target and artifact context

Self-built unexecuted arm64 Mach-O, SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d; caller-selected Ghidra project imported without analysis. Binary and original project file hashes unchanged.

Interface

MCP and CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

Selected Ghidra: Evidence limitation Original analysis completeness and settings are unknown; manifest and index limitations:[], zero indexed functions. Kuna: Evidence limitation reports three omitted entries; index has only procedure_info is unavailable, so function body ranges are unknown. The fresh Ghidra control selected one _evaluate entry. All successful MCP calls used SDK validation with fetched compact schemas. Three Evidence bundles were imported into separate target-free servers: each original export result and its limitations were retained exactly, and bundle hashes were unchanged.

Typed outcome or recovery expected

An explicit inventory/selection observation with its source and scope, retained across the directory handoff, including zero-match, partial and resumed exports. Preserve current output and conflict/cleanup rules and bound any stored text or links.

Analysis or suspected cause

Source-derived: decompileAll obtains selection from list_procedures but builds index limitations from export-specific state; composed-workflow Evidence separately aggregates source limitations. This matches the observed difference. A durable design needs to define whether inventory observations are per run or per accumulated directory before choosing a representation.

Additional context

Related #8351 concerns a top-level body-range warning disappearing on a verified resume while per-function body facts remain; this report is about inventory scope missing from the standalone directory on the first run. #8260 concerns per-file producer state; #8209 concerns bounded graph-to-directory selection; #8352 concerns a separate Kuna classification error. Suggested checks include empty and partial selections, multiple resumes, historical source identities, and avoiding unbounded duplication. Last known good: NOT_ENOUGH_INFO.

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/8355 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `decompile_all` carries limitations of the `list_procedures` inventory in its returned Evidence, but the generated `decompile-index.json` and normalized manifest do not retain those inventory-level limitations. An export directory separated from the tool response can therefore lack facts needed to interpret why functions were selected or omitted. This is separate from per-function caveats, which are retained in each record when there is one. ### Reproduction On REA `d54a4661`, using an owned arm64 Mach-O with three functions, an exported data global, and a Ghidra project imported with `-noanalysis`: 1. Select the saved project with `REA_GHIDRA_PROJECT_PATH` and `REA_GHIDRA_PROGRAM_NAME`, open its matching binary, and call `decompile_all({output_directory:<new>, name:"_evaluate"})`. 2. The returned Evidence says the selected project's original analysis completeness/settings are unknown. Its normalized manifest reports `selected:0, excluded:1, written:0`. The directory index has zero function records and `limitations:[]`; there are no function files that could carry the project caveat. 3. A fresh Ghidra import of the same target with the same filter selected and wrote `_evaluate`. This verifies the difference between these two inventories, not runtime behavior or universal discovery completeness. 4. With real Kuna 1.986 on the same target, an unfiltered export wrote three functions. The returned Evidence warned that Kuna's source inventory also contained three entries that REA omitted based on Mach-O regions. The index retained the separate unknown-body-range limitation, but neither its top-level fields nor its function records/files retained that inventory-omission warning. The selected-project Ghidra and Kuna filtered cases were also run through `rea decompile-all ... --format json`, with and without `--full-output`: CLI output retained the respective Evidence warning, while each index lacked it. Counts and directory contents are observations of the provider inventory, not proof that an unmatched function does or does not exist. ### Expected behavior Make the directory's selection/inventory scope and material inventory limitations accessible alongside its index, or provide another explicit, durable link from the directory to the relevant retained Evidence. Preserve the distinction between inventory-level caveats and per-function observations, including an empty selection. Clarify whether a resumed directory represents the current selection or accumulated selections; do not attach a new run's warning to old files as if it produced them. ### Impact and scope An analyst who retains the Evidence response or exports its Evidence bundle still has the caveat; the issue is the standalone generated directory and normalized manifest. The Ghidra nonempty export's function record and file did retain the general unknown-analysis caveat from their own per-function operations. The zero-selection export had no such record. I did not measure an actual agent misinterpretation. One source-owned fixture and one macOS host were tested; broader provider behavior and interrupted/resumed exports are unverified. ### REA version `d54a4661da20382ad8456564a08569fdd24131c5`. ### Runtime and platform Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21; Kuna 1.986; TypeScript MCP SDK 2.3.1. ### Target and artifact context Self-built unexecuted arm64 Mach-O, SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`; caller-selected Ghidra project imported without analysis. Binary and original project file hashes unchanged. ### Interface MCP and CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence Selected Ghidra: Evidence limitation `Original analysis completeness and settings are unknown`; manifest and index `limitations:[]`, zero indexed functions. Kuna: Evidence limitation reports three omitted entries; index has only `procedure_info is unavailable, so function body ranges are unknown.` The fresh Ghidra control selected one `_evaluate` entry. All successful MCP calls used SDK validation with fetched compact schemas. Three Evidence bundles were imported into separate target-free servers: each original export result and its limitations were retained exactly, and bundle hashes were unchanged. ### Typed outcome or recovery expected An explicit inventory/selection observation with its source and scope, retained across the directory handoff, including zero-match, partial and resumed exports. Preserve current output and conflict/cleanup rules and bound any stored text or links. ### Analysis or suspected cause Source-derived: [`decompileAll`](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/application/decompileDirectory/decompileAll.ts) obtains selection from `list_procedures` but builds index limitations from export-specific state; composed-workflow Evidence separately aggregates source limitations. This matches the observed difference. A durable design needs to define whether inventory observations are per run or per accumulated directory before choosing a representation. ### Additional context Related #8351 concerns a top-level *body-range* warning disappearing on a verified resume while per-function body facts remain; this report is about *inventory* scope missing from the standalone directory on the first run. #8260 concerns per-file producer state; #8209 concerns bounded graph-to-directory selection; #8352 concerns a separate Kuna classification error. Suggested checks include empty and partial selections, multiple resumes, historical source identities, and avoiding unbounded duplication. Last known good: NOT_ENOUGH_INFO. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

bug

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

I exercised multi-selection resumes on current main 6e9ee97a69cb16c7150d8b550e705cba055ee4f0, using the same unexecuted fixture, real Ghidra 12.1.4 and Kuna 1.986, macOS arm64, and MCP SDK 2.3.1 with the fetched compact schemas.

In fresh Ghidra and Kuna sessions, I exported _adjust, resumed with _evaluate, resumed with a name that matched nothing, and resumed _adjust again. The first two runs each selected and wrote one function; the index accumulated both records. The empty run selected zero but retained both records and files; the last run skipped the previously verified _adjust file. All retained file hashes stayed unchanged across the later runs.
In the deliberately unanalyzed selected Ghidra project, an initial _evaluate selection was empty. Resuming with entry wrote one file; another _evaluate run selected zero but retained that record, and a final entry run skipped it. The project-history caveat was present in each response's Evidence, but the index's top-level limitations remained empty. Once the file existed, its own record retained the project-history caveat.
In the Kuna sequence, each response's Evidence retained the inventory-omission warning, but the standalone index did not. The empty and verified-skip resumes also dropped the separate top-level unknown-body warning despite retaining both per-function unknown body facts, reproducing #8351; #8357 addresses that separate body-summary issue.

For all three sequences I exported the retained Evidence and imported it into separate target-free MCP servers. All 12 run records' normalized manifests and limitations matched their live results; bundle hashes were unchanged. The target and original selected-project files were unchanged. Thus preserving an Evidence bundle is an available handoff, although the standalone index does not identify which historical run selected which retained file. This does not establish behavior under changed provider inventory, interrupted writes, other hosts, or arbitrary resume sequences.

The observed accumulated-directory/per-run distinction matters for the design: a latest-run inventory warning or filter should not be presented as the historical selection for every file. A solution can make that distinction explicit or provide durable per-run Evidence links without duplicating an unbounded history into every record.

@morluto commented on GitHub (Oct 31, 2026): I exercised multi-selection resumes on current main `6e9ee97a69cb16c7150d8b550e705cba055ee4f0`, using the same unexecuted fixture, real Ghidra 12.1.4 and Kuna 1.986, macOS arm64, and MCP SDK 2.3.1 with the fetched compact schemas. - In fresh Ghidra and Kuna sessions, I exported `_adjust`, resumed with `_evaluate`, resumed with a name that matched nothing, and resumed `_adjust` again. The first two runs each selected and wrote one function; the index accumulated both records. The empty run selected zero but retained both records and files; the last run skipped the previously verified `_adjust` file. All retained file hashes stayed unchanged across the later runs. - In the deliberately unanalyzed selected Ghidra project, an initial `_evaluate` selection was empty. Resuming with `entry` wrote one file; another `_evaluate` run selected zero but retained that record, and a final `entry` run skipped it. The project-history caveat was present in each response's Evidence, but the index's top-level limitations remained empty. Once the file existed, its own record retained the project-history caveat. - In the Kuna sequence, each response's Evidence retained the inventory-omission warning, but the standalone index did not. The empty and verified-skip resumes also dropped the separate top-level unknown-body warning despite retaining both per-function unknown body facts, reproducing #8351; #8357 addresses that separate body-summary issue. For all three sequences I exported the retained Evidence and imported it into separate target-free MCP servers. All 12 run records' normalized manifests and limitations matched their live results; bundle hashes were unchanged. The target and original selected-project files were unchanged. Thus preserving an Evidence bundle is an available handoff, although the standalone index does not identify which historical run selected which retained file. This does not establish behavior under changed provider inventory, interrupted writes, other hosts, or arbitrary resume sequences. The observed accumulated-directory/per-run distinction matters for the design: a latest-run inventory warning or filter should not be presented as the historical selection for every file. A solution can make that distinction explicit or provide durable per-run Evidence links without duplicating an unbounded history into every record.

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

No description provided.

Rows
Columns