You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every one of this analyzer's seven relationship types has a PY_-prefixed counterpart on the Python side. Project a Python app and a TypeScript app into one database and CALLS is TypeScript-only while PY_CALLS is Python-only — a query written against one silently returns nothing for the other, and any query written against both has to know the asymmetry.
The Python analyzer's own changelog states the intent explicitly: edges are PY_-namespaced "like every other row family so a multi-language database never mingles analyzers' dependence edges."
Prior art — read before starting
PR #7 (patch/ts-prefix-neo4j-schema, "prefix graph labels and relationship types with TS") has been open against main since 2026-06-20 and reports mergeable=UNKNOWN. This issue is not a proposal to redo that work blind — decide first whether to revive, rebase, or supersede it. Filing this because the question is unresolved and undocumented, not because #7 is wrong.
Contract gate
This changes Neo4j output shape, which is a public contract with cross-analyzer parity obligations, so it enters at designing-cldk-changes, not as a direct fix. Two questions it has to settle, and neither is TypeScript-local:
Is the namespace prefix per language (TS_/JS_) or per analyzer family (TS_ covering both)? This is the same artifact-language-vs-family question the roadmap parks as candidate 2 — coining it here would decide it by accident.
Do the twin/generic labels survive? Today a node carries both :Module and :TSModule. If relationships gain a prefix, a bare cross-language query loses its only remaining language-agnostic handle.
Scope boundary
Settles relationship-type namespacing for the Neo4j projection. Does not decide the JSON analysis.json identity question (roadmap candidate 2), and does not add a language discriminator to nodes — a .js module and a .ts module are both :Module:TSModule today with no property distinguishing them, which is a separate gap.
Design session settles per-language vs per-family prefixing, in family-neutral terms so clang and jvm can inherit it
Decide whether generic twin labels stay
Whatever lands, codeanalyzer-python and codeanalyzer-typescript agree — one convention, not two
Caveats and known risks
Breaking for anyone with an existing graph. Renaming relationship types invalidates every stored query and every projected database; it needs a migration path or a schema-version bump, not a silent rename.
Deciding this coins vocabulary permanently. The parity clause makes a prefix scheme unrenameable once shipped — which is exactly why it belongs in a design session rather than a patch.
Do not fix this on the 0.x line. 0.x is the supported line for consumers today but its Neo4j projection is v1; coining the scheme there and again on v2 is the double-coining failure the roadmap already flags.
The v2 line's TS_PREFIX constant is dead (tracked separately) — do not treat its existence as evidence that prefixing is already half-done.
Definition of done
A committed design decision naming the prefix scheme and its scope, in family-neutral terms.
codeanalyzer-python and codeanalyzer-typescript emit relationship types under the same convention, demonstrated by projecting one app from each into a single database and running one query that returns rows from both.
Plan
Found while checking whether JavaScript modules are distinguishable in the Neo4j projection. Planning context: roadmap.
Problem
Node labels are namespaced; relationship types are not. A shared database holding output from more than one analyzer mingles their edges.
What this analyzer emits (verified from a real
--emit neo4jrun on OWASP NodeGoat):What
codeanalyzer-pythonemits for the same concepts (codeanalyzer/neo4j/schema.py):Every one of this analyzer's seven relationship types has a
PY_-prefixed counterpart on the Python side. Project a Python app and a TypeScript app into one database andCALLSis TypeScript-only whilePY_CALLSis Python-only — a query written against one silently returns nothing for the other, and any query written against both has to know the asymmetry.The Python analyzer's own changelog states the intent explicitly: edges are
PY_-namespaced "like every other row family so a multi-language database never mingles analyzers' dependence edges."Prior art — read before starting
PR #7 (
patch/ts-prefix-neo4j-schema, "prefix graph labels and relationship types with TS") has been open againstmainsince 2026-06-20 and reportsmergeable=UNKNOWN. This issue is not a proposal to redo that work blind — decide first whether to revive, rebase, or supersede it. Filing this because the question is unresolved and undocumented, not because #7 is wrong.Contract gate
This changes Neo4j output shape, which is a public contract with cross-analyzer parity obligations, so it enters at
designing-cldk-changes, not as a direct fix. Two questions it has to settle, and neither is TypeScript-local:TS_/JS_) or per analyzer family (TS_covering both)? This is the same artifact-language-vs-family question the roadmap parks as candidate 2 — coining it here would decide it by accident.:Moduleand:TSModule. If relationships gain a prefix, a bare cross-language query loses its only remaining language-agnostic handle.Scope boundary
Settles relationship-type namespacing for the Neo4j projection. Does not decide the JSON
analysis.jsonidentity question (roadmap candidate 2), and does not add a language discriminator to nodes — a.jsmodule and a.tsmodule are both:Module:TSModuletoday with no property distinguishing them, which is a separate gap.Goals
codeanalyzer-pythonandcodeanalyzer-typescriptagree — one convention, not twoCaveats and known risks
TS_PREFIXconstant is dead (tracked separately) — do not treat its existence as evidence that prefixing is already half-done.Definition of done
codeanalyzer-pythonandcodeanalyzer-typescriptemit relationship types under the same convention, demonstrated by projecting one app from each into a single database and running one query that returns rows from both.