What problem does this solve?
Rather than try to catch all possible framework x language combos in current parser-based approach, providing a new tool to register cross-service links would allow both AI and humans to register these links via inference or scripting. This is related to #292 - where it would work in addition to separate configuration file providing this data statically.
I primarily work with Clojure and legacy JS codebase, where built-in parsers are not able to extract any links. Extending parsers is not an option, it would introduce a lot of maintenance burden in the long run. This would effectively allow for building cross-service call graph off band, using internal tooling or letting AI infer these calls at is explores codebases.
Proposed solution
The idea would be to create a new table to store links added via this new tool. This is necessary because currently on reindex all project-level data is removed and rebuilt from scratch. This is similar to #539 in a way.
From there this new tool would maintain list of links, and use that supplementary data source when querying cross-service call graph.
I prototyped it with Claude (last time I touched C was in 2004 ;-)) and it works pretty well - and this storage could then be re-used for all sort of things, including loading data defined by #292
Alternatives considered
No response
Confirmations
What problem does this solve?
Rather than try to catch all possible framework x language combos in current parser-based approach, providing a new tool to register cross-service links would allow both AI and humans to register these links via inference or scripting. This is related to #292 - where it would work in addition to separate configuration file providing this data statically.
I primarily work with Clojure and legacy JS codebase, where built-in parsers are not able to extract any links. Extending parsers is not an option, it would introduce a lot of maintenance burden in the long run. This would effectively allow for building cross-service call graph off band, using internal tooling or letting AI infer these calls at is explores codebases.
Proposed solution
The idea would be to create a new table to store links added via this new tool. This is necessary because currently on reindex all project-level data is removed and rebuilt from scratch. This is similar to #539 in a way.
From there this new tool would maintain list of links, and use that supplementary data source when querying cross-service call graph.
I prototyped it with Claude (last time I touched C was in 2004 ;-)) and it works pretty well - and this storage could then be re-used for all sort of things, including loading data defined by #292
Alternatives considered
No response
Confirmations