From ad813d90200a1f8ceb7aaee58cf5e81239483e50 Mon Sep 17 00:00:00 2001 From: Rahul Krishna Date: Mon, 7 Sep 2026 18:42:38 -0400 Subject: [PATCH 1/2] docs(readme): record the config-read relationships and the entrypoint report MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Section 4 described the graph contract without either. It also claimed every node label is `J`-prefixed, which stopped being true when the repository-artifact layer landed `:Artifact`, `:Package` and `:ConfigKey` unprefixed on purpose — so a sibling-language analyzer over the same repository shares those nodes rather than duplicating them. Adds what a consumer has to know to use the new surface: that `J_USES_CONFIG`'s source is a union of four node families and not always a body node, that unresolved reads are kept rather than dropped, and that the entrypoint report is emitted even when empty because that is the only thing separating "no entrypoints" from "the pass found nothing". --- README.md | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 933b7eb9..07668c51 100644 --- a/README.md +++ b/README.md @@ -207,11 +207,29 @@ comments are `:JComment` nodes in addition to the convenience `docstring` proper The full contract (node labels, their keys and typed properties, relationship types and endpoints, plus the constraint/index DDL) lives in [`schema.neo4j.json`](./schema.neo4j.json) and is visualized -in [`neo4j-schema.drawio`](./neo4j-schema.drawio). All node labels are `J`-prefixed and relationship -types `J_`-prefixed (e.g. `:JType`, `:JCallable`, `J_CALLS`) so a Java graph can share a Neo4j -database with another language's backend without colliding. +in [`neo4j-schema.drawio`](./neo4j-schema.drawio). Java-specific node labels are `J`-prefixed and +relationship types `J_`-prefixed (e.g. `:JType`, `:JCallable`, `J_CALLS`) so a Java graph can share a +Neo4j database with another language's backend without colliding. The exceptions are deliberate: +`:Artifact`, `:Package` and `:ConfigKey` and their containment edges carry **no** prefix, because a +build manifest or a configuration key is not a Java concept — a sibling-language analyzer scanning +the same repository lands on the same nodes instead of a per-language duplicate. `SCHEMA_VERSION` is stamped onto the `:JApplication` node of every emitted graph. +**Configuration reads.** `DEFINES_CONFIG` says which artifact declares a key; `J_USES_CONFIG` says +which code reads one. Its source is whichever node the read was attributed to — a `:JBodyNode` for +a call site (`System.getenv("X")`, `env.getProperty("X")`), or the `:JField` / `:JCallable` / +`:JType` carrying a `@Value("${x}")` or `@ConfigurationProperties` annotation — so a consumer must +not assume it is always a body node. A read that matched no declared key is kept as +`J_READS_CONFIG_UNRESOLVED` rather than dropped, so a read nobody can trace stays as visible as one +that resolves. The literal tier runs at every level; `-a 3` and `-a 4` widen it over the dataflow +graph (`prov: ["dataflow"]`). + +**Entrypoint coverage.** `:JApplication` carries `entrypoint_frameworks` and +`entrypoint_report_json`, and every entrypoint node carries `entrypoint_frameworks` naming the +framework finders that recognised it. The report is present **even when empty**: the detection pass +under-approximates by design, so an empty `frameworks_detected` next to a populated `rulesets` is +what distinguishes "this application has no entrypoints" from "the pass found nothing". + ### 4.1. Cypher snapshot (no database required) ```sh From 44e777e99d74152f8e8cef5eddda38dcf5a2c345 Mon Sep 17 00:00:00 2001 From: Rahul Krishna Date: Mon, 7 Sep 2026 18:42:42 -0400 Subject: [PATCH 2/2] chore(release): 3.1.0 --- gradle.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gradle.properties b/gradle.properties index 84d5af9f..5b2a680f 100644 --- a/gradle.properties +++ b/gradle.properties @@ -1 +1 @@ -version=3.0.3 +version=3.1.0