Neo4j projection omits config-read edges, the entrypoint report, and comments — all three present in codeanalyzer-python

[rahlk]

Problem

Three things Python's analyzer emits and Java's does not. Each makes an SDK accessor answer a degenerate value or refuse, and none is recoverable from what the Java projection carries today.

Measured on a 3.0.3 projection of daytrader8 + thingsboard, against the Python and TypeScript reference graphs.

1. No config-read edges. Java emits DEFINES_CONFIG and nothing else, so get_config_readers() has nothing to read and returns [] unconditionally — the ambiguous empty the SDK refuses everywhere else.

language	config relationship types
Python	DEFINES_CONFIG, PY_USES_CONFIG, PY_READS_CONFIG_UNRESOLVED
TypeScript	DEFINES_CONFIG
Java	DEFINES_CONFIG

Java projects 9,688 :ConfigKey nodes, so the keys are known; what is missing is which callable reads one.

2. No entrypoint report on the application root. MATCH (a:JApplication) RETURN any(k IN keys(a) WHERE k CONTAINS 'entrypoint') is FALSE for Java and TRUE for both siblings. keys(:JApplication) is exactly analyzer_name, analyzer_version, name, schema_version. So get_entrypoint_coverage() reports entrypoint_report_unavailable where the other two answer, even though Java does project 2,604 :JEntrypoint nodes — the marks are there, the report about how they were found is not.

3. No comment nodes in the projection. Zero nodes carrying a comment label. analysis.json has comments, so the in-process backend answers and the graph backend raises — a split that is invisible to a caller choosing a backend.

Scope boundary

In scope: those three. Out of scope: CRUD (#187), and the can:// id missing from the :JApplication root (codeanalyzer-schema#5).

Goals

• A relationship linking a callable to the config key it reads, and the unresolved-read counterpart, matching what codeanalyzer-python emits
• The entrypoint report on the application root, in the shape the siblings already use
• Comments projected, so the graph and JSON backends answer the comment accessors alike

Caveats and known risks

• The parity clause applies: these terms exist in codeanalyzer-python already. Match those names rather than coining new ones — a term coined twice is permanently wrong.
• TypeScript has the same config gap and should probably move in the same release, so the three analyzers do not end up with three vocabularies.
• Comments are bulky. If projecting them wholesale is too costly, say so and propose what a caller actually needs, rather than projecting a subset silently.

Definition of done

• The three python-sdk accessors that degrade or refuse on a Java graph answer, with no SDK change beyond reading the new data.

[rahlk]

Investigated all three goals against the current projector and codeanalyzer-python. Two of them hold; one does not, and the definition of done needs revising. Superseded by codellm-devkit/.github#62, with the spec at codellm-devkit/.github → docs/design/specs/2026-09-07-java-config-reads-and-entrypoint-report.md.

Goal 1 — config-read edges: confirmed, and larger than stated

The gap is real, but it is not a projection gap. Java has no config-use analysis at all: artifacts/ConfigKeys.java only flattens artifact text into :ConfigKey declarations. codeanalyzer-python has a whole detection-and-resolution pass (codeanalyzer/artifacts/config_use.py) feeding app.config_uses / app.config_reads_unresolved. So this is a new backend pass plus two new analysis.json lists, then projection — not wiring an existing fact into the graph.

Two things "match those names rather than coining new ones" could not settle on its own:

• Python's names are language-prefixed — PY_USES_CONFIG, PY_READS_CONFIG_UNRESOLVED (neo4j/schema.py:296,305). Java's convention is J_. Parity is on shape, so: J_USES_CONFIG / J_READS_CONFIG_UNRESOLVED.
• PY_USES_CONFIG runs PyBodyNode → ConfigKey, anchoring a read on a call site — because Python's config reads are calls. Java's dominant idiom is @Value("${db.url}") / @ConfigurationProperties, an annotation with no call site to anchor on. Locked: src widens to the annotated element (JBodyNode for call-site reads, JCallable/JField/JType for annotation reads). Call-sites-only would be literal parity that reports almost nothing on a Spring app — most of the daytrader8 corpus this was measured on.

Also locked: the literal tier runs at L1, not python's L2, because JBodyNode already carries argument_expr/receiver_type/method_name at L1; an L3/L4 dataflow tier widens it additively.

Goal 2 — entrypoint report: confirmed exactly as described

V2SchemaCatalog.java:100-102 gives :JApplication precisely name, schema_version, analyzer_name, analyzer_version. Java's five finders return bare booleans; there is no report object anywhere in the analyzer. Python's shape is PyEntrypointReport{frameworks_detected, rulesets, unresolved, errors} projected as entrypoint_frameworks: string[] + entrypoint_report_json: string. Java will adopt the same four keys — rulesets being the five finder names, which is Java's ruleset vocabulary.

Goal 3 — comments: the premise does not hold

codeanalyzer-python does not project comment nodes either. There is no :PyComment node type in codeanalyzer/neo4j/schema.py, and neo4j/project.py:843 collapses comments into a single docstring property — which is exactly what V2GraphProjector.docstringOf (:595) does in Java. python-sdk documents it as a deliberate ceiling:

Projection-lossy fields (inherent to what the graph stores): comments collapse to a single docstring (module-level comments dropped)
— cldk/analysis/python/neo4j/neo4j_backend.py:73

So there is no parity gap here and no python term to match. Dropped from scope. Projecting comment nodes is still a reasonable thing to want, but it would be a new capability with no sibling precedent — including the bulk-cost decision this issue asked for — not the parity fix described here.

Definition of done — not reachable as written

The three python-sdk accessors that degrade or refuse on a Java graph answer, with no SDK change beyond reading the new data.

get_config_readers and get_entrypoint_coverage exist only on the Python analysis surface (cldk/analysis/python/). The Java surface has neither — grep "def get_config\|def get_entrypoint" cldk/analysis/java/ returns nothing. So python-sdk needs new Java-side accessors regardless of what the analyzer emits; there is no "just read the new data" path. That is tracked as a deferred child of the epic, and the epic states the consequence plainly: the analyzer will emit this data before anything consumes it.

One correction to the framing

The epic does not bump the graph contract. V2SchemaCatalog.SCHEMA_VERSION is deliberately held at 2.0.0 (the class javadoc's "2.2.0" is stale text) because this analyzer already drifted alone once and undid it; a re-baseline is codellm-devkit/.github#50's call. Consequence recorded rather than papered over: a consumer cannot detect J_USES_CONFIG from schema_version alone until #50 lands.

[rahlk]

Superseded by codellm-devkit/.github#62 (epic) and #232 (first work item). Goals 1 and 2 carried forward with the divergences resolved; goal 3 dropped — codeanalyzer-python does not project comment nodes either, so there was no parity gap to close. See the comment above for the full grounding.

[rahlk]

Alignment note from codeanalyzer-typescript #182 (same gap, now landing): the TypeScript projection spells the unresolved-read edge TS_READS_CONFIG_UNRESOLVED, python's shape verbatim — :Application → :External ghost of the read root or the resolved callee, properties key (only for undefined-key), reason (non-literal | undefined-key), prov[], discriminant _k = "<key>|<reason>", no per-site identity (python's documented collapse: several sites reading one (callee, key, reason) become one relationship). Decision record: docs/design/specs/neo4j-bindings-parameters-config.md D5 on that repo.

For Java the parity-clause spelling is JAVA_READS_CONFIG_UNRESOLVED with the same properties and _k, so get_config_readers / get_unresolved_config_reads can be one Cypher shape per language prefix. Java already carries J_IMPORTS and parameters_json, so this is the only one of #182's three that applies here.