[GH-ISSUE #404] Add runtime semantic tracing for generated JavaScript applications #247

Closed
opened 2026-10-15 18:22:58 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Jul 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/404

Problem

The JavaScript Application Graph is useful for structural mapping, but generated CLI and Electron bundles often require semantic questions that an AST/module inventory cannot answer:

  • Which minified value reaches this request field?
  • Which promise owns this background task?
  • Does shutdown await, cancel, or abandon it?
  • Which listener receives this signal or event?
  • Which environment/config value wins by precedence?
  • Where is external JSON coerced into a domain value?
  • Are two reformatted/versioned minified functions behaviorally the same candidate?

Without bounded semantic tracing, agents fall back to manual bundle reading, fragile text search, or runtime harnesses for questions that could be narrowed statically.

Proposal

Add a bounded JavaScript runtime-semantics graph and trace workflow layered on the existing authenticated JavaScript Application Graph.

This remains static analysis unless separately correlated with runtime Evidence. It must never report a path as executed merely because it is statically reachable.

Required semantic relations

  • local and interprocedural def-use edges;
  • parameter/argument and return-value flow;
  • object-property reads, writes, spreads, destructuring, and aliases;
  • closure captures;
  • promise creation, chaining, await, all, allSettled, and detached-task ownership;
  • event-emitter/listener registration, removal, and dispatch candidates;
  • timers and cancellation handles;
  • child-process spawn, stdio, exit/error listeners, signal forwarding, and ownership candidates;
  • environment, argv, config, and default/precedence propagation;
  • HTTP/WebSocket/JSON-RPC request construction and response-consumer candidates;
  • boundary coercion and validation paths from unknown JSON to stable shapes;
  • cleanup/resource acquisition and release candidates;
  • stable semantic fingerprints across formatting, bundling, and minifier renaming.

Bounded query model

Queries should start from an authenticated literal, application-graph node, function, property, endpoint, event name, or boundary field and declare:

  • direction: backward provenance, forward influence, callers, consumers, or ownership;
  • maximum nodes/edges/depth/functions/modules;
  • allowed relation kinds;
  • source-map authority if any;
  • whether ambiguous dynamic-property/call edges may be included;
  • expected sink/source class.

Results should be pageable and identify exact source spans, module/function identities, relation kind, confidence, ambiguity, truncation frontier, and unsupported syntax.

Minified/versioned code

Stable function fingerprints should combine bounded normalized evidence such as:

  • literal and endpoint sets;
  • control-flow shape;
  • call/property relation shape;
  • parameter/return arity;
  • async/event/process effects;
  • source-map identity when separately authenticated.

Names and module ordinals alone are never sufficient. Duplicate fingerprints remain ambiguous. Cross-version matches must use the same conservative unique-only rules as other REA comparison workflows.

Static/runtime reconciliation

Runtime Evidence may confirm that a statically identified listener, process spawn, request, or boundary was observed. Correlation must require explicit mappings or exact identities and report hypotheses separately from causal proof.

Acceptance criteria

  • A versioned semantic graph schema covers the required relation families.
  • Analysis is bounded, pageable, deterministic, and Evidence v2-backed.
  • Def-use traces work across closures and direct interprocedural calls.
  • Promise ownership distinguishes awaited, aggregated, returned, and detached chains.
  • Event-emitter analysis links literal registrations/removals/dispatches and leaves dynamic names unresolved.
  • Child-process analysis records argv/env/stdio/listener/signal ownership candidates.
  • Request construction traces object fields back to argv/env/config/default sources.
  • Boundary traces identify parse/coercion/validation consumers without claiming runtime execution.
  • Stable fingerprints match formatting/minifier-only changes and reject ambiguous duplicates.
  • Truncation, dynamic calls/properties, eval, unsupported syntax, and incomplete bundles remain explicit unknowns.
  • A query failure reports actionable limits and the accepted ranges in CLI and MCP schemas.
  • Fixtures include generated/minified CLI, Webpack/Rspack chunks, Electron preload IPC, promise teardown, and child-process signal flows.
  • Documentation clearly separates structural reachability, semantic inference, runtime observation, and causal proof.

Non-goals

  • Executing untrusted JavaScript as part of static analysis.
  • Claiming complete whole-program points-to analysis for arbitrary dynamic JavaScript.
  • Recovering original identifiers or source.
  • Treating source maps as authoritative without separate authentication.
Originally created by @morluto on GitHub (Jul 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/404 ## Problem The JavaScript Application Graph is useful for structural mapping, but generated CLI and Electron bundles often require semantic questions that an AST/module inventory cannot answer: - Which minified value reaches this request field? - Which promise owns this background task? - Does shutdown await, cancel, or abandon it? - Which listener receives this signal or event? - Which environment/config value wins by precedence? - Where is external JSON coerced into a domain value? - Are two reformatted/versioned minified functions behaviorally the same candidate? Without bounded semantic tracing, agents fall back to manual bundle reading, fragile text search, or runtime harnesses for questions that could be narrowed statically. ## Proposal Add a bounded JavaScript runtime-semantics graph and trace workflow layered on the existing authenticated JavaScript Application Graph. This remains static analysis unless separately correlated with runtime Evidence. It must never report a path as executed merely because it is statically reachable. ## Required semantic relations - local and interprocedural def-use edges; - parameter/argument and return-value flow; - object-property reads, writes, spreads, destructuring, and aliases; - closure captures; - promise creation, chaining, `await`, `all`, `allSettled`, and detached-task ownership; - event-emitter/listener registration, removal, and dispatch candidates; - timers and cancellation handles; - child-process spawn, stdio, exit/error listeners, signal forwarding, and ownership candidates; - environment, argv, config, and default/precedence propagation; - HTTP/WebSocket/JSON-RPC request construction and response-consumer candidates; - boundary coercion and validation paths from unknown JSON to stable shapes; - cleanup/resource acquisition and release candidates; - stable semantic fingerprints across formatting, bundling, and minifier renaming. ## Bounded query model Queries should start from an authenticated literal, application-graph node, function, property, endpoint, event name, or boundary field and declare: - direction: backward provenance, forward influence, callers, consumers, or ownership; - maximum nodes/edges/depth/functions/modules; - allowed relation kinds; - source-map authority if any; - whether ambiguous dynamic-property/call edges may be included; - expected sink/source class. Results should be pageable and identify exact source spans, module/function identities, relation kind, confidence, ambiguity, truncation frontier, and unsupported syntax. ## Minified/versioned code Stable function fingerprints should combine bounded normalized evidence such as: - literal and endpoint sets; - control-flow shape; - call/property relation shape; - parameter/return arity; - async/event/process effects; - source-map identity when separately authenticated. Names and module ordinals alone are never sufficient. Duplicate fingerprints remain ambiguous. Cross-version matches must use the same conservative unique-only rules as other REA comparison workflows. ## Static/runtime reconciliation Runtime Evidence may confirm that a statically identified listener, process spawn, request, or boundary was observed. Correlation must require explicit mappings or exact identities and report hypotheses separately from causal proof. ## Acceptance criteria - [ ] A versioned semantic graph schema covers the required relation families. - [ ] Analysis is bounded, pageable, deterministic, and Evidence v2-backed. - [ ] Def-use traces work across closures and direct interprocedural calls. - [ ] Promise ownership distinguishes awaited, aggregated, returned, and detached chains. - [ ] Event-emitter analysis links literal registrations/removals/dispatches and leaves dynamic names unresolved. - [ ] Child-process analysis records argv/env/stdio/listener/signal ownership candidates. - [ ] Request construction traces object fields back to argv/env/config/default sources. - [ ] Boundary traces identify parse/coercion/validation consumers without claiming runtime execution. - [ ] Stable fingerprints match formatting/minifier-only changes and reject ambiguous duplicates. - [ ] Truncation, dynamic calls/properties, `eval`, unsupported syntax, and incomplete bundles remain explicit unknowns. - [ ] A query failure reports actionable limits and the accepted ranges in CLI and MCP schemas. - [ ] Fixtures include generated/minified CLI, Webpack/Rspack chunks, Electron preload IPC, promise teardown, and child-process signal flows. - [ ] Documentation clearly separates structural reachability, semantic inference, runtime observation, and causal proof. ## Non-goals - Executing untrusted JavaScript as part of static analysis. - Claiming complete whole-program points-to analysis for arbitrary dynamic JavaScript. - Recovering original identifiers or source. - Treating source maps as authoritative without separate authentication.
bsakaguchi 2026-10-15 18:22:58 +00:00
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#247
No description provided.