morluto/rea

Fork 0

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

[GH-ISSUE #8351] [Bug] Decompile resume drops the top-level unknown-body limitation #6558

New issue

Open

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Native analysis or decompilation

Observed behavior

A no-op decompile_all resume removes the top-level body-coverage limitation from the returned manifest and rewritten index, even though the index still contains the same function with body.available: false and the same reason. The per-function unknown is retained; the loss is in the top-level summary, not in the file or function record.

Reproduction

On REA 60149282fcfc05ac32fbc94434c107710120da6f, macOS arm64 and real Kuna 1.986, use a source-owned unexecuted Mach-O with a function _audit_3 and a new output directory:

rea decompile-all <target> --provider kuna --output <new-dir> --name _audit_3 --format json writes one file. The manifest and decompile-index.json both include procedure_info is unavailable, so function body ranges are unknown. The function record has body: {available: false, reason: ...}.
Repeat with --resume. It exits 0 with selected: 1, requested: 0, skipped: 1, written: 0. The function file SHA-256 is unchanged and its index record still reports the unavailable body, but both the returned manifest's limitations and the index's top-level limitations are now [].

Real MCP reproduced the same write/skip sequence after exporting other functions to the directory. An empty exact-range resume also cleared the top-level limitation. A Ghidra 12.1.4 control on the same target had available body ranges and an empty top-level list both before and after. The target SHA-256 c025eb0e222a025941ec2ac4666db019029f7e24254d45fd2f953315b2228e67 was unchanged; no target was executed. One target/provider combination and the Ghidra control were exercised; natural frequency is not measured.

Expected behavior

Keep the existing per-function unknowns and file-preservation behavior. Clarify whether top-level limitations describe the current attempt or the accumulated directory, and make the returned manifest and index unambiguous for that scope. If the index summarizes the accumulated directory, derive the body-coverage caveat from retained records as well as new work. An empty list should not invite a reader to infer that previously unavailable body ranges became available.

Impact and scope

A caller reading only the manifest or index's top-level limitations loses the earlier cue after a verified skip. The per-function body record continues to state the unknown, and the pseudocode file and its digest remain intact. No agent misinterpretation or data loss beyond the summary was measured. Other limitations, failures, concurrent resumes and operating systems remain untested.

REA version

60149282fcfc05ac32fbc94434c107710120da6f

Runtime and platform

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

Target and artifact context

Self-built arm64 Mach-O with a 20-function call chain; static analysis only. NOT_ENOUGH_INFO: the fixture is not attached; the behavior was observed in the local source-owned build.

Interface

CLI and MCP

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

First Kuna export: counts: {selected: 1, requested: 1, written: 1}, top-level limitation present, per-function body.available: false. Matching resume: counts: {selected: 1, requested: 0, skipped: 1, written: 0}, top-level limitation absent, same per-function unavailable body and same file digest. MCP successful responses were validated using fetched compact SDK schemas.

Typed outcome or recovery expected

Preserve or explicitly scope summary limitations across no-op, partial and filtered resumes; retain each recorded body status and per-item limitations without re-decompiling verified files.

Analysis or suspected cause

Source inspection: decompileAll initializes state.bodyUnavailable to false each call; it sets the flag only when a newly attempted procedure_info is unavailable. A verified existing file is skipped before that path, and exportLimitations and writeIndex receive the current-call flag. This explains the observed skip; it is not a claim about every possible index limitation.

Additional context

Related #7351 concerned per-function caveats lost during unreadable/conflicting resumes and is closed; here the per-function body fact is preserved but the top-level summary disappears on a verified skip. Related graph-selected export discussion: #8209. Test real CLI/MCP, no-op and empty-selection resumes, mixed available/unavailable bodies, conflicts and new writes; avoid claiming graph coverage from an empty limitation list. 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/8351 ### 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 Native analysis or decompilation ### Observed behavior A no-op `decompile_all` resume removes the top-level body-coverage limitation from the returned manifest and rewritten index, even though the index still contains the same function with `body.available: false` and the same reason. The per-function unknown is retained; the loss is in the top-level summary, not in the file or function record. ### Reproduction On REA `60149282fcfc05ac32fbc94434c107710120da6f`, macOS arm64 and real Kuna 1.986, use a source-owned unexecuted Mach-O with a function `_audit_3` and a new output directory: 1. `rea decompile-all <target> --provider kuna --output <new-dir> --name _audit_3 --format json` writes one file. The manifest and `decompile-index.json` both include `procedure_info is unavailable, so function body ranges are unknown.` The function record has `body: {available: false, reason: ...}`. 2. Repeat with `--resume`. It exits 0 with `selected: 1`, `requested: 0`, `skipped: 1`, `written: 0`. The function file SHA-256 is unchanged and its index record still reports the unavailable body, but both the returned manifest's `limitations` and the index's top-level `limitations` are now `[]`. Real MCP reproduced the same write/skip sequence after exporting other functions to the directory. An empty exact-range resume also cleared the top-level limitation. A Ghidra 12.1.4 control on the same target had available body ranges and an empty top-level list both before and after. The target SHA-256 `c025eb0e222a025941ec2ac4666db019029f7e24254d45fd2f953315b2228e67` was unchanged; no target was executed. One target/provider combination and the Ghidra control were exercised; natural frequency is not measured. ### Expected behavior Keep the existing per-function unknowns and file-preservation behavior. Clarify whether top-level limitations describe the current attempt or the accumulated directory, and make the returned manifest and index unambiguous for that scope. If the index summarizes the accumulated directory, derive the body-coverage caveat from retained records as well as new work. An empty list should not invite a reader to infer that previously unavailable body ranges became available. ### Impact and scope A caller reading only the manifest or index's top-level limitations loses the earlier cue after a verified skip. The per-function `body` record continues to state the unknown, and the pseudocode file and its digest remain intact. No agent misinterpretation or data loss beyond the summary was measured. Other limitations, failures, concurrent resumes and operating systems remain untested. ### REA version `60149282fcfc05ac32fbc94434c107710120da6f` ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.986 and Ghidra 12.1.4 / JDK 21; MCP SDK 2.3.1. ### Target and artifact context Self-built arm64 Mach-O with a 20-function call chain; static analysis only. `NOT_ENOUGH_INFO`: the fixture is not attached; the behavior was observed in the local source-owned build. ### Interface CLI and MCP ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence First Kuna export: `counts: {selected: 1, requested: 1, written: 1}`, top-level limitation present, per-function `body.available: false`. Matching resume: `counts: {selected: 1, requested: 0, skipped: 1, written: 0}`, top-level limitation absent, same per-function unavailable body and same file digest. MCP successful responses were validated using fetched compact SDK schemas. ### Typed outcome or recovery expected Preserve or explicitly scope summary limitations across no-op, partial and filtered resumes; retain each recorded body status and per-item limitations without re-decompiling verified files. ### Analysis or suspected cause Source inspection: `decompileAll` initializes `state.bodyUnavailable` to false each call; it sets the flag only when a newly attempted `procedure_info` is unavailable. A verified existing file is skipped before that path, and `exportLimitations` and `writeIndex` receive the current-call flag. This explains the observed skip; it is not a claim about every possible index limitation. ### Additional context Related #7351 concerned per-function caveats lost during unreadable/conflicting resumes and is closed; here the per-function body fact is preserved but the top-level summary disappears on a verified skip. Related graph-selected export discussion: #8209. Test real CLI/MCP, no-op and empty-selection resumes, mixed available/unavailable bodies, conflicts and new writes; avoid claiming graph coverage from an empty limitation list. Last known good: NOT_ENOUGH_INFO. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

bug

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

The existing focused source suite separates these ingredients: one test verifies the limitation and file header when procedure_info is unavailable on a fresh write; another verifies that a matching resume skips existing files. Neither of those two assertions checks the top-level body-coverage limitation after a skip. I ran this 59-test file on the same main revision during the related export audit and it passed. This explains why those checks do not exercise this combination; it is not a claim that no other test anywhere could detect it.

A useful regression is the public real-provider create → verified no-op resume sequence above, asserting both the per-function body fact and the intended scope of top-level limitations. Keep a provider with available ranges as a control, and retain existing conflict, cancellation and partial-failure checks. Decide the index/manifest scope before asserting a particular output representation.

@morluto commented on GitHub (Oct 31, 2026): The existing focused source suite separates these ingredients: one test verifies the limitation and file header when `procedure_info` is unavailable on a fresh write; another verifies that a matching resume skips existing files. Neither of those two assertions checks the top-level body-coverage limitation after a skip. I ran this 59-test file on the same main revision during the related export audit and it passed. This explains why those checks do not exercise this combination; it is not a claim that no other test anywhere could detect it. A useful regression is the public real-provider create → verified no-op resume sequence above, asserting both the per-function body fact and the intended scope of top-level limitations. Keep a provider with available ranges as a control, and retain existing conflict, cancellation and partial-failure checks. Decide the index/manifest scope before asserting a particular output representation.

bsakaguchi commented

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

Author

Owner

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

Isolated directory-scope experiment

I tested an unmerged experiment on 60149282 in a detached worktree. It asks the existing journal owner whether any committed current record has body.available: false and, when the current call did not already report procedure_info unavailable, adds a neutral directory-scoped caveat directing the reader to each record's reason. It does not inspect or classify the reason text, re-decompile skipped files, or alter the journal.

Real Kuna 1.986 CLI create → matching resume retained the file hash and unavailable body record. The initial manifest/index kept the existing procedure_info caveat; the no-op resume now returned the neutral directory caveat in both. A real MCP empty-range resume over three existing Kuna records likewise retained the neutral caveat. Real Ghidra 12.1.4 on the same fixture had available bodies and no such caveat. Successful compact SDK schemas validated; target hash was unchanged and no target executed.
A separate production-boundary control with a simulated provider returned valid procedure_info for two functions: one body available, the other body unavailable with the provider's own reason. The experiment reported the neutral directory caveat on creation, a resume selecting only the known-body function, and an empty-selection resume; it did not claim that procedure_info was unsupported. A new directory containing only the available body and an empty directory had no such caveat. This is not real-provider behavior.
The existing 59-test decompileAll.test.ts source suite passed in the experiment. It does not establish the missing regression by itself; the real create/resume and simulated mixed-body controls above are separate manual checks.

This exposes the scope decision: the proposed caveat describes all committed records in the output directory, not only functions selected or attempted in the latest call. That distinction is useful but could surprise a caller reading a filtered manifest. It also broadens fresh-call reporting when the provider successfully returns procedure_info but cannot supply a particular body. A final design must explicitly choose and document manifest versus index scope, consider failed/external records and old journals, and test cancellation, conflicts, mixed outcomes and all supported adapters. This experiment is not a production-ready fix and does not establish any provider's general completeness. No production or user-worktree files were changed.

@morluto commented on GitHub (Oct 31, 2026): ### Isolated directory-scope experiment I tested an unmerged experiment on `60149282` in a detached worktree. It asks the existing journal owner whether any **committed current record** has `body.available: false` and, when the current call did not already report `procedure_info` unavailable, adds a neutral directory-scoped caveat directing the reader to each record's reason. It does not inspect or classify the reason text, re-decompile skipped files, or alter the journal. - Real Kuna 1.986 CLI create → matching resume retained the file hash and unavailable body record. The initial manifest/index kept the existing `procedure_info` caveat; the no-op resume now returned the neutral directory caveat in both. A real MCP empty-range resume over three existing Kuna records likewise retained the neutral caveat. Real Ghidra 12.1.4 on the same fixture had available bodies and no such caveat. Successful compact SDK schemas validated; target hash was unchanged and no target executed. - A separate production-boundary control with a **simulated** provider returned valid `procedure_info` for two functions: one body available, the other body unavailable with the provider's own reason. The experiment reported the neutral directory caveat on creation, a resume selecting only the known-body function, and an empty-selection resume; it did not claim that `procedure_info` was unsupported. A new directory containing only the available body and an empty directory had no such caveat. This is not real-provider behavior. - The existing 59-test `decompileAll.test.ts` source suite passed in the experiment. It does not establish the missing regression by itself; the real create/resume and simulated mixed-body controls above are separate manual checks. This exposes the scope decision: the proposed caveat describes **all committed records in the output directory**, not only functions selected or attempted in the latest call. That distinction is useful but could surprise a caller reading a filtered manifest. It also broadens fresh-call reporting when the provider successfully returns `procedure_info` but cannot supply a particular body. A final design must explicitly choose and document manifest versus index scope, consider failed/external records and old journals, and test cancellation, conflicts, mixed outcomes and all supported adapters. This experiment is not a production-ready fix and does not establish any provider's general completeness. No production or user-worktree files were changed.

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

No description provided.

Rows
Columns