rea/docs/javascript-application-workflows.md

Cross-layer JavaScript application workflows

REA derives a complete reachable feature trace from one authenticated JavaScript Application Graph and compares two authenticated graph versions. The MCP tools are inspect_analysis_view, trace_application_feature, trace_javascript_semantics, compare_application_versions, compare_source_to_bundle, and compare_javascript_export_shapes; their CLI equivalents use the same names with hyphens. inspect_analysis_view projects a summary, module page, or one module from already completed application Evidence; it does not walk relationships.

inspect_analysis_view also projects retained inspect_binary_layout Evidence. The remaining workflows consume Evidence produced by analyze_javascript_application or reconcile_javascript_runtime. They do not read an artifact, execute application code, attach to a process, or open a native-analysis provider. Static artifact observations, passive runtime observations, relationship inferences, and unknown or unavailable facts retain their original graph authority.

analyze_javascript_application Evidence retains the structural JavaScript Application Graph and a separate semantic relation graph bound to the same root artifact digest and structural graph ID. Semantic tracing requires the semantic relation graph and reports when it is unavailable rather than treating missing data as an empty graph.

Explicit TypeScript import type and export type declarations remain source facts and do not create runtime import or export relationships. Type export names are reported separately from value export names. Inline type specifiers can leave an empty import or re-export with side effects under verbatimModuleSyntax; REA retains those dependency candidates and reports the unavailable compiler options rather than assuming the dependency is erased.

The semantic graph wire format stores shared non-location provenance once in its required evidence_contexts table. Each node, relation, fingerprint, and unknown retains its exact evidence.location and names the owning context with evidence.context_id. This is a breaking representation change: consumers reading fields such as evidence.authority must look up the context by ID and combine its fields with the fact's location. Semantic trace results include the canonical context subset referenced by their returned facts, so those facts remain self-contained in the response.

Feature tracing

Select one literal seed kind: node ID, route, string, API, IPC channel, module, or native export. Matching is exact or literal substring matching; regular expressions and executable predicates are not accepted. The trace includes all matching seeds and the complete graph reachable in the selected direction.

The result contains the matching basis, complete reachable subgraph, terminal paths, authority summaries, and native handoffs. A handoff binds the exact native artifact digest and requested exports from the application graph. Existing Hopper or Ghidra Evidence is linked only when its subject digest matches exactly. Otherwise the result recommends provider-neutral follow-up tools and reports requires-provider-analysis; it never starts or switches a provider implicitly.

Semantic relation tracing

trace_javascript_semantics queries the authenticated companion graph without rereading mutable files. A seed may identify a semantic or application node, literal, function fingerprint, property, endpoint, event, or boundary field. For a recovered parse, coercion, or validation boundary, its field value is the static operation's method name (for example, Number). The query declares backward provenance, forward influence, callers, or ownership and can restrict admitted relation kinds. REA returns every matching seed and the complete reachable subgraph; callers do not choose n