[GH-ISSUE #7741] [Feature] trace_application_feature: report semantic-graph matches when the application graph has none #4632

New issue

Closed

opened 2026-10-31 00:51:37 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:51:37 +00:00

Owner

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

Before submitting

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

Reproduced on rea-agents 6.8.0 (released) and on main 6a226bd09.

Seed `{"kind":"string","value":"rpc","match":"exact"}`, direction `both`	6.8.0 (npm, Node 26.12.1)	main `6a226bd09` (source, Node 24.22.1)
Semantic-graph nodes labeled `rpc` in the source Evidence	7	7
`trace_application_feature` result	`coverage.status: "no-match"`, `matched_seeds: 0`	`coverage.status: "no-match"`, `matched_seeds: 0`

Area

JavaScript application workflows, trace_application_feature and trace_javascript_semantics.

Current limitation

trace_application_feature matches its seed only against the application
graph (findApplicationFeatureSeeds(input.graph.nodes, input.seed) in
src/domain/javascript/javascriptFeatureTrace.ts). The semantic graph
(normalized_result.semantic_graph), which holds functions, bindings, call
sites and property slots, is not searched. When the seed names something that
exists only there, the result is coverage.status: "no-match" with the
limitation "No graph entity matched the literal seed; this is not evidence that
the feature is absent."

The semantic graph has its own tool, trace_javascript_semantics, with a
different seed and query model. A caller who starts from a feature name does
not learn from the no-match result that the second tool could find it.

This is a source-derived finding. I did not build a minimal seed that exists
only in the semantic graph; the original report (6.4.0, MCP) was a seed that
matched semantic nodes but returned no application match.

Use cases

Start a trace from a name seen in the bundle (a function, a property, an
operation string) without knowing which graph holds it.

Desired outcome and success criteria

One of:

When the application graph has no match, trace_application_feature reports
the semantic-graph matches it can see (node ids and kinds) and recommends
trace_javascript_semantics with a ready seed; or
A documented graph: "application" | "semantic" input, or a semantic
fallback, with the semantic node's application_node_ids used as
application-graph seeds.

Success: a seed present only in the semantic graph no longer ends as an
unexplained no-match.

Expected interaction with targets

Reads existing Evidence only.

#7738 (direction "both" returns the whole graph)
#7740 (call arguments are not retained as literals, so such seeds do not exist in either graph)

Verification available so far

Run on rea-agents 6.8.0 (npm, Node 26.12.1) and upstream main at 6a226bd09 (source, Node 24.22.1): the seed rpc names 7 semantic-graph nodes and returns no-match (table above). The source reading above explains why.

Originally created by @jgt87 on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7741 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. Reproduced on rea-agents 6.8.0 (released) and on main 6a226bd09. | Seed `{"kind":"string","value":"rpc","match":"exact"}`, direction `both` | 6.8.0 (npm, Node 26.12.1) | main 6a226bd09 (source, Node 24.22.1) | | --- | --- | --- | | Semantic-graph nodes labeled `rpc` in the source Evidence | 7 | 7 | | `trace_application_feature` result | `coverage.status: "no-match"`, `matched_seeds: 0` | `coverage.status: "no-match"`, `matched_seeds: 0` | ## Area JavaScript application workflows, `trace_application_feature` and `trace_javascript_semantics`. ## Current limitation `trace_application_feature` matches its seed only against the application graph (`findApplicationFeatureSeeds(input.graph.nodes, input.seed)` in `src/domain/javascript/javascriptFeatureTrace.ts`). The semantic graph (`normalized_result.semantic_graph`), which holds functions, bindings, call sites and property slots, is not searched. When the seed names something that exists only there, the result is `coverage.status: "no-match"` with the limitation "No graph entity matched the literal seed; this is not evidence that the feature is absent." The semantic graph has its own tool, `trace_javascript_semantics`, with a different seed and query model. A caller who starts from a feature name does not learn from the no-match result that the second tool could find it. This is a source-derived finding. I did not build a minimal seed that exists only in the semantic graph; the original report (6.4.0, MCP) was a seed that matched semantic nodes but returned no application match. ## Use cases - Start a trace from a name seen in the bundle (a function, a property, an operation string) without knowing which graph holds it. ## Desired outcome and success criteria One of: 1. When the application graph has no match, `trace_application_feature` reports the semantic-graph matches it can see (node ids and kinds) and recommends `trace_javascript_semantics` with a ready seed; or 2. A documented `graph: "application" | "semantic"` input, or a semantic fallback, with the semantic node's `application_node_ids` used as application-graph seeds. Success: a seed present only in the semantic graph no longer ends as an unexplained `no-match`. ## Expected interaction with targets Reads existing Evidence only. ## Related - #7738 (direction "both" returns the whole graph) - #7740 (call arguments are not retained as literals, so such seeds do not exist in either graph) ## Verification available so far Run on rea-agents 6.8.0 (npm, Node 26.12.1) and upstream `main` at 6a226bd09 (source, Node 24.22.1): the seed `rpc` names 7 semantic-graph nodes and returns `no-match` (table above). The source reading above explains why.

bsakaguchi closed this issue

2026-10-31 00:51:37 +00:00

bsakaguchi referenced this issue

2026-10-31 01:14:27 +00:00

[PR #4838] [MERGED] fix(javascript): admit CommonJS bare scoped package directory resolution #6436