morluto/rea

Fork 0

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

[GH-ISSUE #8236] [Design] Allow caller-bounded native call graph investigation #6502

New issue

Open

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

bsakaguchi commented

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

Owner

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

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 an analyst be able to request an explicitly bounded native call-path or call-graph traversal, with a truthful partial result and an optional way to continue, while preserving today's unbounded default?

Context and evidence

On a self-built, unexecuted arm64 Mach-O with a 20-function direct-call chain and a separate unrelated function, real REA MCP with Ghidra 12.1.4 and Kuna 1.986 returned a three-node path when the requested goal was two calls away. Asking for the unrelated goal returned not_reached after visiting all 20 observed chain functions. get_call_graph(detail: summary) retained and summarized all 20 graph nodes; summary changes delivery, not traversal selection. These are small controlled fixtures; no elapsed-time, CPU or general scalability claim is made.

Both providers also accepted trace_native_ui_action with the first function as a native seed and max_depth: 2: it returned three function nodes and two edges, with truncated: true, reason: native_call_traversal_bound_reached and partial static-call coverage. That is an existing bounded workflow, but it is UI-oriented, marks UI archives unsupported on this non-bundle, and does not answer a generic selected-goal question. Provider coverage and representations differ; a reported static route is not runtime reachability.

Current trace_call_path and get_call_graph input schemas have no caller-selected traversal budget. Source inspection shows breadth-first traversal stops on the selected goal or graph exhaustion; the graph's summary is a view after traversal. Cancellation is available but does not itself return a completed partial traversal and can have provider/session consequences. #4247 proposes several goals and explicitly rejects a default depth limit; an optional caller budget would be a separate choice, not a mandatory limit.

Expected interaction with targets

Read selected local binaries and query the configured static provider. No target execution or mutation is proposed.

Boundary details (optional)

A reached goal is supported by the observed path; a goal not reached before a caller budget is exhausted must remain unknown, not not_reached. Distinguish caller-imposed depth/node/work limits, provider partial or unknown relationship coverage, cancellation, actual graph exhaustion, and output pagination. Preserve address-space identity, provider Evidence, selected goal/direction, and source limitations. If continuation is supported, bind it to target, profile, direction, selection and retained traversal state; do not assume live provider state remains fresh.

Options and tradeoffs

Compare documenting composition from individual relationship calls and the existing native-seeded UI trace, an optional explicit max_depth/node budget on existing traversal contracts, or a retained/resumable graph investigation. Avoid introducing arbitrary defaults or presenting a partial graph as a complete negative. Page size is an output choice and should not be confused with a work budget. Any limits must reflect caller selection or a documented resource constraint and fit docs/tool-design.md.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Test short reached path, unreachable goal in a fully examined graph, goal beyond a selected bound, unresolved or failed expansions, cycles, multiple parents, both directions and zero/edge boundaries through CLI/MCP with real and controlled providers. Verify shortest-path and remaining-frontier semantics, cancellation and cleanup, snapshot identity, and selected limits. Evaluate completed representative tasks including tool calls/context and resource costs before claiming an efficiency benefit. The 20-node control does not establish production-scale performance or autonomous-agent decisions.

References

Related #4247 (multiple goals, no default depth limit), #8200 (call-site evidence), #8235 (paged depth ordering), and #8209 (graph-selected export).
Source revision 53a4ab78451a0654e9c3beb3d43a5e371a288fcc; call-path traversal.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8236 ### 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 an analyst be able to request an explicitly bounded native call-path or call-graph traversal, with a truthful partial result and an optional way to continue, while preserving today's unbounded default? ### Context and evidence On a self-built, unexecuted arm64 Mach-O with a 20-function direct-call chain and a separate unrelated function, real REA MCP with Ghidra 12.1.4 and Kuna 1.986 returned a three-node path when the requested goal was two calls away. Asking for the unrelated goal returned `not_reached` after visiting all 20 observed chain functions. `get_call_graph(detail: summary)` retained and summarized all 20 graph nodes; summary changes delivery, not traversal selection. These are small controlled fixtures; no elapsed-time, CPU or general scalability claim is made. Both providers also accepted `trace_native_ui_action` with the first function as a native seed and `max_depth: 2`: it returned three function nodes and two edges, with `truncated: true`, `reason: native_call_traversal_bound_reached` and partial static-call coverage. That is an existing bounded workflow, but it is UI-oriented, marks UI archives unsupported on this non-bundle, and does not answer a generic selected-goal question. Provider coverage and representations differ; a reported static route is not runtime reachability. Current `trace_call_path` and `get_call_graph` input schemas have no caller-selected traversal budget. Source inspection shows breadth-first traversal stops on the selected goal or graph exhaustion; the graph's summary is a view after traversal. Cancellation is available but does not itself return a completed partial traversal and can have provider/session consequences. #4247 proposes several goals and explicitly rejects a default depth limit; an optional caller budget would be a separate choice, not a mandatory limit. ### Expected interaction with targets Read selected local binaries and query the configured static provider. No target execution or mutation is proposed. ### Boundary details (optional) A reached goal is supported by the observed path; a goal not reached before a caller budget is exhausted must remain unknown, not `not_reached`. Distinguish caller-imposed depth/node/work limits, provider partial or unknown relationship coverage, cancellation, actual graph exhaustion, and output pagination. Preserve address-space identity, provider Evidence, selected goal/direction, and source limitations. If continuation is supported, bind it to target, profile, direction, selection and retained traversal state; do not assume live provider state remains fresh. ### Options and tradeoffs Compare documenting composition from individual relationship calls and the existing native-seeded UI trace, an optional explicit `max_depth`/node budget on existing traversal contracts, or a retained/resumable graph investigation. Avoid introducing arbitrary defaults or presenting a partial graph as a complete negative. Page size is an output choice and should not be confused with a work budget. Any limits must reflect caller selection or a documented resource constraint and fit `docs/tool-design.md`. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Test short reached path, unreachable goal in a fully examined graph, goal beyond a selected bound, unresolved or failed expansions, cycles, multiple parents, both directions and zero/edge boundaries through CLI/MCP with real and controlled providers. Verify shortest-path and remaining-frontier semantics, cancellation and cleanup, snapshot identity, and selected limits. Evaluate completed representative tasks including tool calls/context and resource costs before claiming an efficiency benefit. The 20-node control does not establish production-scale performance or autonomous-agent decisions. ### References - Related #4247 (multiple goals, no default depth limit), #8200 (call-site evidence), #8235 (paged depth ordering), and #8209 (graph-selected export). - Source revision `53a4ab78451a0654e9c3beb3d43a5e371a288fcc`; [call-path traversal](https://github.com/morluto/rea/blob/53a4ab78451a0654e9c3beb3d43a5e371a288fcc/src/application/CallPathTracing.ts).

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

2026-11-01 21:11:44 +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:44 +00:00

Author

Owner

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

CLI verification clarification: the current CLI does not appear to expose the generic trace_call_path workflow used in this report. On the same call-chain fixture, rea trace accepts a literal feature query, and rea trace-call-path returned command-not-found; two rea function calls did expose the individual edges. Real MCP with both Ghidra and Kuna still reached the three-node path. The success criterion above mentions future CLI coverage; a separate task-level CLI design question is now #8321, rather than assuming this bounded-traversal issue already has a CLI surface.

@morluto commented on GitHub (Oct 31, 2026): CLI verification clarification: the current CLI does not appear to expose the generic `trace_call_path` workflow used in this report. On the same call-chain fixture, `rea trace` accepts a literal feature query, and `rea trace-call-path` returned command-not-found; two `rea function` calls did expose the individual edges. Real MCP with both Ghidra and Kuna still reached the three-node path. The success criterion above mentions future CLI coverage; a separate task-level CLI design question is now #8321, rather than assuming this bounded-traversal issue already has a CLI surface.

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

No description provided.

Rows
Columns