morluto/rea

Fork 0

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

[GH-ISSUE #8181] [Design] Distinguish a missing batch decompilation selection from an empty batch #6466

New issue

Open

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

bsakaguchi commented

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

Owner

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

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 batch_decompile require an explicit addresses list so that an omitted selection cannot be mistaken for a completed decompilation request? Should an explicitly empty list remain a supported no-op?

Context and evidence

On REA working tree based on 47fa6ab3795d547207001ffb01643c0aa39dcad8, macOS arm64 and Ghidra 12.1.4, I used the real stdio MCP transport and opened a self-built Mach-O. tools/list advertised batch_decompile without a required addresses property. Both batch_decompile({}) and batch_decompile({"addresses":[]}) returned successful Evidence with items: [], total: 0, succeeded: 0, failed: 0. The counts accurately say no work was performed. A mixed batch containing one known function and one unresolved selector returned an ordered partial result, so this request is specifically about omission, not batch failure handling.

The canonical input schema uses .default([]), so this is current intended behavior rather than a schema/runtime contradiction. An agent might omit the list because the advertised property is optional, but no controlled model-selection trial has established that this happens in practice.

Expected interaction with targets

Read selected local binaries and launch/use the selected analysis provider. An empty batch performs no decompilation; no target execution or mutation is proposed.

Boundary details (optional)

Preserve the caller's distinction between an absent selection and an explicitly empty one if they have different meanings. Report a missing required field through the existing invalid-input recovery contract. Do not infer a selection from the active target or silently decompile every function; that is a separate decompile_all workflow.

Options and tradeoffs

Compare requiring addresses while allowing an explicit empty list for programmatic composition, versus requiring at least one item. Either changes the accepted input contract and needs CLI/MCP and direct-dispatch analysis. Leaving the behavior unchanged may be appropriate if empty no-op calls are an intentional public workflow; document that rationale and surface it in the tool description. The separate upper-bound question is #5930; no arbitrary maximum is proposed here.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Test omitted, explicit empty, one valid item and mixed success/failure through public MCP and any CLI entry point; verify ordering and per-item outcomes remain intact. A controlled agent trace would establish whether omission actually affects task success.

References

Canonical schema: github.com/morluto/rea@47fa6ab379/src/contracts/enhancedInputs.ts

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8181 ### 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 Should `batch_decompile` require an explicit `addresses` list so that an omitted selection cannot be mistaken for a completed decompilation request? Should an explicitly empty list remain a supported no-op? ### Context and evidence On REA working tree based on `47fa6ab3795d547207001ffb01643c0aa39dcad8`, macOS arm64 and Ghidra 12.1.4, I used the real stdio MCP transport and opened a self-built Mach-O. `tools/list` advertised `batch_decompile` without a required `addresses` property. Both `batch_decompile({})` and `batch_decompile({"addresses":[]})` returned successful Evidence with `items: []`, `total: 0`, `succeeded: 0`, `failed: 0`. The counts accurately say no work was performed. A mixed batch containing one known function and one unresolved selector returned an ordered partial result, so this request is specifically about omission, not batch failure handling. The canonical input schema uses `.default([])`, so this is current intended behavior rather than a schema/runtime contradiction. An agent might omit the list because the advertised property is optional, but no controlled model-selection trial has established that this happens in practice. ### Expected interaction with targets Read selected local binaries and launch/use the selected analysis provider. An empty batch performs no decompilation; no target execution or mutation is proposed. ### Boundary details (optional) Preserve the caller's distinction between an absent selection and an explicitly empty one if they have different meanings. Report a missing required field through the existing invalid-input recovery contract. Do not infer a selection from the active target or silently decompile every function; that is a separate `decompile_all` workflow. ### Options and tradeoffs Compare requiring `addresses` while allowing an explicit empty list for programmatic composition, versus requiring at least one item. Either changes the accepted input contract and needs CLI/MCP and direct-dispatch analysis. Leaving the behavior unchanged may be appropriate if empty no-op calls are an intentional public workflow; document that rationale and surface it in the tool description. The separate upper-bound question is #5930; no arbitrary maximum is proposed here. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Test omitted, explicit empty, one valid item and mixed success/failure through public MCP and any CLI entry point; verify ordering and per-item outcomes remain intact. A controlled agent trace would establish whether omission actually affects task success. ### References Canonical schema: https://github.com/morluto/rea/blob/47fa6ab3795d547207001ffb01643c0aa39dcad8/src/contracts/enhancedInputs.ts

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

2026-11-01 21:11:22 +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.

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

No description provided.

Rows
Columns