[GH-ISSUE #482] [Feature] Trace native state and value dependencies across functions #258

Closed
opened 2026-10-15 18:23:04 +00:00 by bsakaguchi · 2 comments
Owner

Originally created by @morluto on GitHub (Sep 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/482

Before submitting

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

Area

Native analysis or decompilation

Current limitation

REA provides bounded function dossiers, caller/callee traversal, string-to-code tracing, and cross-references. These operations identify useful procedures, but they do not yet produce a bounded value/state slice that explains how a feature's inputs flow through predicates and mutations across multiple procedures. Native call graphs also report that unresolved indirect calls may be missing. As a result, explaining a multi-step rule often requires manually decompiling many functions and reassembling field reads, random draws, thresholds, and state writes.

Use cases

  • Explain which inputs and conditions cause a model state to advance or a transaction to settle.
  • Trace how configuration fields, user choices, history values, and random draws affect an outcome.
  • Connect a UI action or localized message to the state mutations and later simulation effects it can trigger.
  • Find all relevant readers/writers of a model field and distinguish initialization, normal updates, and cleanup paths.

Current analyze_function, get_call_graph, xrefs, trace_feature, and build_call_path operations provide source evidence for parts of this work, but require manual cross-function reconstruction and do not claim dataflow dependencies.

Desired outcome and success criteria

Add a bounded native semantic-trace operation that accepts explicit seeds such as a procedure address, symbol/class/member, selector/string, or typed field address and returns an evidence-linked dependency graph. Where supported, report:

  • exact procedures and call/reference edges traversed, including resolved dispatch targets and the dispatch mechanism;
  • field/global reads and writes, with before/after or produced-value relationships when recoverable;
  • constants, configuration/table references, arithmetic operators, RNG sources/ranges, branch predicates, and relevant comparison thresholds;
  • state mutations and observable sinks such as returned values, calls, events, accounting records, or I/O operations;
  • unresolved indirect calls, missing types, ambiguous slices, unsupported operations, and traversal truncation as explicit unknowns.

Every inferred dependency must cite the procedure/reference evidence that supports it and carry a confidence/authority label. The operation must cap depth, nodes, edges, decompilation work, and output size; preserve typed distinctions between direct, indirect, inferred, and unavailable relationships; and paginate large results. A successful report should be enough to explain a bounded state transition without implying recovery of original source code.

Fixture acceptance should include source-built native examples for direct and indirect calls, struct/global fields, enum/state changes, configuration data, random bounds, branches, and multiple mutations. Expected traces should be checked against known source/assembly semantics, while optimized and stripped fixtures must return truthful unknowns instead of fabricated paths.

Authority boundaries and non-goals

  • Static analysis only; do not execute the target or infer observed runtime behavior from pseudocode.
  • No claim of source-code recovery or complete whole-program dynamic call-graph reconstruction.
  • Keep analyzer-specific artifacts and evidence provenance visible; do not collapse unresolved edges into confirmed edges.
  • Respect existing provider operation budgets, cancellation, session binding, and evidence limits.

Alternatives considered

  • Manually calling analyze_function and get_call_graph for every suspected helper works but creates a long, fragile sequence and still requires the agent to infer data dependencies.
  • trace_feature is useful when matching literals exist; formulas and state transitions frequently have no helpful literal anchor.
  • xrefs can find references to a known address but cannot explain value flow from inputs to a predicate or mutation.

Possible direction

Compose existing function dossiers, typed references, class/type metadata, and a provider's decompiler IR or p-code into a sparse, bounded backward/forward slice. Add language-specific Swift/Objective-C dispatch resolution as evidence becomes available; keep unsupported dispatch forms explicit.

References

  • Function dossier completeness: #31 and #54
  • Feature-trace budget reporting: #261
  • Ghidra provider evaluation: #26
Originally created by @morluto on GitHub (Sep 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/482 ## Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Native analysis or decompilation ## Current limitation REA provides bounded function dossiers, caller/callee traversal, string-to-code tracing, and cross-references. These operations identify useful procedures, but they do not yet produce a bounded value/state slice that explains how a feature's inputs flow through predicates and mutations across multiple procedures. Native call graphs also report that unresolved indirect calls may be missing. As a result, explaining a multi-step rule often requires manually decompiling many functions and reassembling field reads, random draws, thresholds, and state writes. ## Use cases - Explain which inputs and conditions cause a model state to advance or a transaction to settle. - Trace how configuration fields, user choices, history values, and random draws affect an outcome. - Connect a UI action or localized message to the state mutations and later simulation effects it can trigger. - Find all relevant readers/writers of a model field and distinguish initialization, normal updates, and cleanup paths. Current `analyze_function`, `get_call_graph`, `xrefs`, `trace_feature`, and `build_call_path` operations provide source evidence for parts of this work, but require manual cross-function reconstruction and do not claim dataflow dependencies. ## Desired outcome and success criteria Add a bounded native semantic-trace operation that accepts explicit seeds such as a procedure address, symbol/class/member, selector/string, or typed field address and returns an evidence-linked dependency graph. Where supported, report: - exact procedures and call/reference edges traversed, including resolved dispatch targets and the dispatch mechanism; - field/global reads and writes, with before/after or produced-value relationships when recoverable; - constants, configuration/table references, arithmetic operators, RNG sources/ranges, branch predicates, and relevant comparison thresholds; - state mutations and observable sinks such as returned values, calls, events, accounting records, or I/O operations; - unresolved indirect calls, missing types, ambiguous slices, unsupported operations, and traversal truncation as explicit unknowns. Every inferred dependency must cite the procedure/reference evidence that supports it and carry a confidence/authority label. The operation must cap depth, nodes, edges, decompilation work, and output size; preserve typed distinctions between direct, indirect, inferred, and unavailable relationships; and paginate large results. A successful report should be enough to explain a bounded state transition without implying recovery of original source code. Fixture acceptance should include source-built native examples for direct and indirect calls, struct/global fields, enum/state changes, configuration data, random bounds, branches, and multiple mutations. Expected traces should be checked against known source/assembly semantics, while optimized and stripped fixtures must return truthful unknowns instead of fabricated paths. ## Authority boundaries and non-goals - Static analysis only; do not execute the target or infer observed runtime behavior from pseudocode. - No claim of source-code recovery or complete whole-program dynamic call-graph reconstruction. - Keep analyzer-specific artifacts and evidence provenance visible; do not collapse unresolved edges into confirmed edges. - Respect existing provider operation budgets, cancellation, session binding, and evidence limits. ## Alternatives considered - Manually calling `analyze_function` and `get_call_graph` for every suspected helper works but creates a long, fragile sequence and still requires the agent to infer data dependencies. - `trace_feature` is useful when matching literals exist; formulas and state transitions frequently have no helpful literal anchor. - `xrefs` can find references to a known address but cannot explain value flow from inputs to a predicate or mutation. ## Possible direction Compose existing function dossiers, typed references, class/type metadata, and a provider's decompiler IR or p-code into a sparse, bounded backward/forward slice. Add language-specific Swift/Objective-C dispatch resolution as evidence becomes available; keep unsupported dispatch forms explicit. ## References - Function dossier completeness: #31 and #54 - Feature-trace budget reporting: #261 - Ghidra provider evaluation: #26
bsakaguchi 2026-10-15 18:23:04 +00:00
Author
Owner

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

One additional acceptance case from reverse-engineering a shipped simulation is a periodic report/event pipeline: a week/quarter gate selects a producer; model-state predicates determine eligibility; ordering or ranking chooses a subject; the producer queues a typed event; then a shared feed applies category/weight rules and binds the event to a presentation resource.

A useful trace should preserve the distinctions between eligible and selected, constructed and queued, and queued and demonstrably rendered. This prevents a constructor or inbox insertion from being overstated as a visible result. The case also exercises interprocedural state dependencies, table/config inputs, scheduler/callback edges, and unresolved subclass dispatch without requiring application-specific semantics in REA.

<!-- gh-comment-id:5958149385 --> @morluto commented on GitHub (Oct 2, 2026): One additional acceptance case from reverse-engineering a shipped simulation is a periodic report/event pipeline: a week/quarter gate selects a producer; model-state predicates determine eligibility; ordering or ranking chooses a subject; the producer queues a typed event; then a shared feed applies category/weight rules and binds the event to a presentation resource. A useful trace should preserve the distinctions between eligible and selected, constructed and queued, and queued and demonstrably rendered. This prevents a constructor or inbox insertion from being overstated as a visible result. The case also exercises interprocedural state dependencies, table/config inputs, scheduler/callback edges, and unresolved subclass dispatch without requiring application-specific semantics in REA.
Author
Owner

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

Verified fixed on main (7a7460f0). trace_native_values is wired through enhancedToolContracts + CLI coreNativeCommands with NativeValueTrace service and passing tests (2/2). Closing per audit.

<!-- gh-comment-id:6071375906 --> @morluto commented on GitHub (Oct 8, 2026): Verified fixed on main (7a7460f0). trace_native_values is wired through enhancedToolContracts + CLI coreNativeCommands with NativeValueTrace service and passing tests (2/2). Closing per audit.
Sign in to join this conversation.
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#258
No description provided.