gitnexus 1.6.5-rc.13 → 1.6.5-rc.15

package/dist/core/incremental/shadow-candidates.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Shadow-candidate path derivation for incremental indexing.
+ *
+ * Background — Bugbot review on PR #1479:
+ *   queryImporters() on a NEWLY ADDED file returns 0 importers in the
+ *   pre-pipeline DB, because the new file's IMPORTS rows haven't been
+ *   written yet. But pre-existing files may have IMPORTS edges that
+ *   *resolved to a sibling path*, and the newcomer can now steal that
+ *   resolution under standard JS/TS module-resolution rules. Without
+ *   pulling those pre-existing files into the writable set, their
+ *   stale CALLS edges remain pointing at the OLD resolution target.
+ *
+ * Given an added file path, this helper enumerates the pre-existing
+ * file paths whose import-resolution claim the newcomer can steal.
+ * Caller filters the candidates against the prior-run `fileHashes`
+ * map so we only query importers of paths that actually existed.
+ *
+ * Shadow patterns covered (resolution-priority-aware):
+ *
+ *   (a) Same basename, different extension —
+ *       added `foo/bar.ts` shadows `foo/bar.{tsx,js,jsx,mjs,cjs,d.ts}`.
+ *   (b) Bare-file beats directory-style index —
+ *       added `foo/bar.ts` shadows `foo/bar/index.{ts,tsx,...}`.
+ *   (c) Directory-index beats bare-file —
+ *       added `foo/index.ts` shadows `foo.{ts,tsx,...}` (rare but real,
+ *       e.g. converting a single-file module into a directory module).
+ *
+ * Resolution-order priority is conservatively wide: we enumerate ALL
+ * common extensions because we don't know which the importer actually
+ * specified, and over-seeding is harmless (extra BFS work, but the
+ * subgraph extract still gates write-back by file membership).
+ *
+ * Cross-platform path separators: candidates are emitted with both `/`
+ * and `\` for shadow pattern (b), since the caller's prior fileHashes
+ * map may use either depending on the OS that wrote it.
+ */
+/**
+ * Enumerate pre-existing paths whose import-resolution `added` can steal.
+ *
+ * @param added — repo-relative path of a newly-added file
+ * @returns deduplicated list of candidate paths (NOT filtered against
+ *          any known-files set — caller does that)
+ */
+export declare const shadowCandidatesFor: (added: string) => string[];

package/dist/core/incremental/shadow-candidates.js

@@ -0,0 +1,74 @@
+/**
+ * Shadow-candidate path derivation for incremental indexing.
+ *
+ * Background — Bugbot review on PR #1479:
+ *   queryImporters() on a NEWLY ADDED file returns 0 importers in the
+ *   pre-pipeline DB, because the new file's IMPORTS rows haven't been
+ *   written yet. But pre-existing files may have IMPORTS edges that
+ *   *resolved to a sibling path*, and the newcomer can now steal that
+ *   resolution under standard JS/TS module-resolution rules. Without
+ *   pulling those pre-existing files into the writable set, their
+ *   stale CALLS edges remain pointing at the OLD resolution target.
+ *
+ * Given an added file path, this helper enumerates the pre-existing
+ * file paths whose import-resolution claim the newcomer can steal.
+ * Caller filters the candidates against the prior-run `fileHashes`
+ * map so we only query importers of paths that actually existed.
+ *
+ * Shadow patterns covered (resolution-priority-aware):
+ *
+ *   (a) Same basename, different extension —
+ *       added `foo/bar.ts` shadows `foo/bar.{tsx,js,jsx,mjs,cjs,d.ts}`.
+ *   (b) Bare-file beats directory-style index —
+ *       added `foo/bar.ts` shadows `foo/bar/index.{ts,tsx,...}`.
+ *   (c) Directory-index beats bare-file —
+ *       added `foo/index.ts` shadows `foo.{ts,tsx,...}` (rare but real,
+ *       e.g. converting a single-file module into a directory module).
+ *
+ * Resolution-order priority is conservatively wide: we enumerate ALL
+ * common extensions because we don't know which the importer actually
+ * specified, and over-seeding is harmless (extra BFS work, but the
+ * subgraph extract still gates write-back by file membership).
+ *
+ * Cross-platform path separators: candidates are emitted with both `/`
+ * and `\` for shadow pattern (b), since the caller's prior fileHashes
+ * map may use either depending on the OS that wrote it.
+ */
+const SHADOW_EXTS = ['.d.ts', '.tsx', '.ts', '.jsx', '.js', '.mjs', '.cjs'];
+/**
+ * Enumerate pre-existing paths whose import-resolution `added` can steal.
+ *
+ * @param added — repo-relative path of a newly-added file
+ * @returns deduplicated list of candidate paths (NOT filtered against
+ *          any known-files set — caller does that)
+ */
+export const shadowCandidatesFor = (added) => {
+    const ext = SHADOW_EXTS.find((e) => added.endsWith(e));
+    if (!ext)
+        return [];
+    const noExt = added.slice(0, -ext.length);
+    const out = new Set();
+    // (a) Same basename, different extension.
+    for (const alt of SHADOW_EXTS) {
+        if (alt !== ext)
+            out.add(noExt + alt);
+    }
+    // (b) Bare file beats sibling directory-style index.
+    for (const idx of SHADOW_EXTS) {
+        out.add(`${noExt}/index${idx}`);
+        out.add(`${noExt}\\index${idx}`);
+    }
+    // (c) New `foo/index.ext` shadows old `foo.ext`.
+    const idxSuffixSlash = '/index';
+    const idxSuffixBack = '\\index';
+    let dir = null;
+    if (noExt.endsWith(idxSuffixSlash))
+        dir = noExt.slice(0, -idxSuffixSlash.length);
+    else if (noExt.endsWith(idxSuffixBack))
+        dir = noExt.slice(0, -idxSuffixBack.length);
+    if (dir !== null) {
+        for (const alt of SHADOW_EXTS)
+            out.add(dir + alt);
+    }
+    return [...out];
+};

package/dist/core/incremental/subgraph-extract.d.ts

@@ -0,0 +1,64 @@
+/**
+ * Subgraph extraction for incremental DB writeback.
+ *
+ * Given the FULL ctx.graph produced by the pipeline (all files parsed,
+ * all phases run) and the set of file paths whose DB rows must be
+ * replaced, produce a smaller KnowledgeGraph that contains:
+ *
+ *   - Every node whose `properties.filePath` is in `toWriteSet`.
+ *   - Every graph-wide node (Community, Process) — these are regenerated
+ *     each run by the communities/processes phases and must be fully
+ *     rewritten.
+ *   - Every relationship where AT LEAST ONE endpoint is in the writable
+ *     set above. Relationships entirely between unchanged-file nodes
+ *     are skipped — their rows are still in the DB and re-inserting
+ *     them would PK-conflict at COPY time.
+ *
+ * The resulting subgraph is what gets passed to `loadGraphToLbug` after
+ * the orchestrator has deleted the corresponding DB rows. Hydrated
+ * unchanged-file rows are never touched in the DB.
+ *
+ * # Cross-file edge consistency (Finding 1)
+ *
+ * `extractChangedSubgraph` intentionally does NOT expand the set it is
+ * given — expansion is the orchestrator's job, so the SAME expanded set
+ * can be fed to both `deleteNodesForFile` and this function (asymmetry
+ * between the delete set and the write set silently corrupts the DB).
+ * `computeEffectiveWriteSet` below performs the boundary-crossing 1-hop
+ * walk; the orchestrator composes it with its importer-BFS expansion and
+ * passes the result here.
+ *
+ * Why the 1-hop walk is needed: consider a barrel re-export change —
+ * file C (a barrel) shifts `export { foo } from './b'` to
+ * `export { foo } from './d'`. After scope resolution, file A's CALLS
+ * edge to `foo` resolves to D instead of B, even though A's content is
+ * byte-for-byte identical:
+ *
+ *   - Old A→B edge survives in DB (neither A nor B is changed → not deleted)
+ *   - New A→D edge is missing (neither A nor D in writable set → skipped)
+ *
+ * Pulling the unchanged-side file of every writable-boundary-crossing
+ * edge into the write set fixes both halves: the orchestrator's
+ * `DETACH DELETE` cleans up the stale unchanged-side rows, and the new
+ * cross-file edges land because at least one endpoint is now writable.
+ *
+ * Limitation (documented): if a file X *stopped* importing from a
+ * changed file C, X has no edge to C in the new graph, so this 1-hop
+ * walk doesn't catch it. The orchestrator's importer-BFS (which reads
+ * IMPORTS from the pre-pipeline DB) covers that case instead.
+ */
+import type { KnowledgeGraph } from '../graph/types.js';
+export declare const extractChangedSubgraph: (fullGraph: KnowledgeGraph, toWriteSet: ReadonlySet<string>) => KnowledgeGraph;
+/**
+ * Public — derive the EFFECTIVE write-set: `toWriteSet` expanded by one
+ * hop along every edge in the new graph that crosses the writable
+ * boundary (one endpoint in a writable file, the other in an unchanged
+ * file). The unchanged-side file is pulled in so its stale rows are
+ * deleted + rewritten in lockstep with the changed side.
+ *
+ * Single pass over the edge list. Does NOT mutate `toWriteSet`. The
+ * orchestrator MUST feed the returned set to both `deleteNodesForFile`
+ * and `extractChangedSubgraph` — feeding the unexpanded set to either
+ * one leaves stale rows or PK-conflicts at COPY time.
+ */
+export declare const computeEffectiveWriteSet: (fullGraph: KnowledgeGraph, toWriteSet: ReadonlySet<string>) => Set<string>;

package/dist/core/incremental/subgraph-extract.js

@@ -0,0 +1,111 @@
+/**
+ * Subgraph extraction for incremental DB writeback.
+ *
+ * Given the FULL ctx.graph produced by the pipeline (all files parsed,
+ * all phases run) and the set of file paths whose DB rows must be
+ * replaced, produce a smaller KnowledgeGraph that contains:
+ *
+ *   - Every node whose `properties.filePath` is in `toWriteSet`.
+ *   - Every graph-wide node (Community, Process) — these are regenerated
+ *     each run by the communities/processes phases and must be fully
+ *     rewritten.
+ *   - Every relationship where AT LEAST ONE endpoint is in the writable
+ *     set above. Relationships entirely between unchanged-file nodes
+ *     are skipped — their rows are still in the DB and re-inserting
+ *     them would PK-conflict at COPY time.
+ *
+ * The resulting subgraph is what gets passed to `loadGraphToLbug` after
+ * the orchestrator has deleted the corresponding DB rows. Hydrated
+ * unchanged-file rows are never touched in the DB.
+ *
+ * # Cross-file edge consistency (Finding 1)
+ *
+ * `extractChangedSubgraph` intentionally does NOT expand the set it is
+ * given — expansion is the orchestrator's job, so the SAME expanded set
+ * can be fed to both `deleteNodesForFile` and this function (asymmetry
+ * between the delete set and the write set silently corrupts the DB).
+ * `computeEffectiveWriteSet` below performs the boundary-crossing 1-hop
+ * walk; the orchestrator composes it with its importer-BFS expansion and
+ * passes the result here.
+ *
+ * Why the 1-hop walk is needed: consider a barrel re-export change —
+ * file C (a barrel) shifts `export { foo } from './b'` to
+ * `export { foo } from './d'`. After scope resolution, file A's CALLS
+ * edge to `foo` resolves to D instead of B, even though A's content is
+ * byte-for-byte identical:
+ *
+ *   - Old A→B edge survives in DB (neither A nor B is changed → not deleted)
+ *   - New A→D edge is missing (neither A nor D in writable set → skipped)
+ *
+ * Pulling the unchanged-side file of every writable-boundary-crossing
+ * edge into the write set fixes both halves: the orchestrator's
+ * `DETACH DELETE` cleans up the stale unchanged-side rows, and the new
+ * cross-file edges land because at least one endpoint is now writable.
+ *
+ * Limitation (documented): if a file X *stopped* importing from a
+ * changed file C, X has no edge to C in the new graph, so this 1-hop
+ * walk doesn't catch it. The orchestrator's importer-BFS (which reads
+ * IMPORTS from the pre-pipeline DB) covers that case instead.
+ */
+import { createKnowledgeGraph } from '../graph/graph.js';
+const isGraphWide = (label) => label === 'Community' || label === 'Process';
+/**
+ * Build a Map<nodeId, filePath> for every File-bound node in the graph.
+ * Graph-wide nodes (Community/Process) have no filePath and are filtered.
+ */
+const indexNodeFilePaths = (fullGraph) => {
+    const idx = new Map();
+    fullGraph.forEachNode((n) => {
+        const fp = n.properties?.filePath;
+        if (fp)
+            idx.set(n.id, fp);
+    });
+    return idx;
+};
+export const extractChangedSubgraph = (fullGraph, toWriteSet) => {
+    const sub = createKnowledgeGraph();
+    const writableNodeIds = new Set();
+    fullGraph.forEachNode((n) => {
+        const filePath = n.properties?.filePath;
+        const include = (filePath && toWriteSet.has(filePath)) || isGraphWide(n.label);
+        if (include) {
+            sub.addNode(n);
+            writableNodeIds.add(n.id);
+        }
+    });
+    fullGraph.forEachRelationship((r) => {
+        if (writableNodeIds.has(r.sourceId) || writableNodeIds.has(r.targetId)) {
+            sub.addRelationship(r);
+        }
+    });
+    return sub;
+};
+/**
+ * Public — derive the EFFECTIVE write-set: `toWriteSet` expanded by one
+ * hop along every edge in the new graph that crosses the writable
+ * boundary (one endpoint in a writable file, the other in an unchanged
+ * file). The unchanged-side file is pulled in so its stale rows are
+ * deleted + rewritten in lockstep with the changed side.
+ *
+ * Single pass over the edge list. Does NOT mutate `toWriteSet`. The
+ * orchestrator MUST feed the returned set to both `deleteNodesForFile`
+ * and `extractChangedSubgraph` — feeding the unexpanded set to either
+ * one leaves stale rows or PK-conflicts at COPY time.
+ */
+export const computeEffectiveWriteSet = (fullGraph, toWriteSet) => {
+    const nodeFilePaths = indexNodeFilePaths(fullGraph);
+    const expanded = new Set(toWriteSet);
+    fullGraph.forEachRelationship((r) => {
+        const sourcePath = nodeFilePaths.get(r.sourceId);
+        const targetPath = nodeFilePaths.get(r.targetId);
+        if (!sourcePath || !targetPath)
+            return; // skip edges to graph-wide nodes
+        const sourceWritable = toWriteSet.has(sourcePath);
+        const targetWritable = toWriteSet.has(targetPath);
+        if (sourceWritable && !targetWritable)
+            expanded.add(targetPath);
+        else if (targetWritable && !sourceWritable)
+            expanded.add(sourcePath);
+    });
+    return expanded;
+};

package/dist/core/ingestion/call-processor.js

@@ -30,7 +30,7 @@ import { isRegistryPrimary } from './registry-primary-flag.js';
 import { isVerboseIngestionEnabled } from './utils/verbose.js';
 import { yieldToEventLoop } from './utils/event-loop.js';
 import { parseSourceSafe } from '../tree-sitter/safe-parse.js';
-import { FUNCTION_NODE_TYPES, findEnclosingClassId, findEnclosingClassInfo, genericFuncName, inferFunctionLabel, } from './utils/ast-helpers.js';
+import { CLASS_CONTAINER_TYPES, FUNCTION_NODE_TYPES, findEnclosingClassInfo, genericFuncName, inferFunctionLabel, } from './utils/ast-helpers.js';
 import { typeTagForId, constTagForId, buildCollisionGroups } from './utils/method-props.js';
 import { countCallArguments, inferCallForm, extractReceiverName, extractReceiverNode, extractMixedChain, extractCallArgTypes, } from './utils/call-analysis.js';
 import { buildTypeEnv, isSubclassOf } from './type-env.js';
@@ -39,6 +39,57 @@ import { normalizeFetchURL, routeMatches } from './route-extractors/nextjs.js';
 import { extractTemplateComponents } from './vue-sfc-extractor.js';
 import { extractReturnTypeName, stripNullable } from './type-extractors/shared.js';
 import { logger } from '../logger.js';
+// ── Property-prepass helpers (parity with parse-worker.ts) ──
+// These mirror the sequential-path equivalents in parse-worker.ts so the main-
+// thread `processCalls` pre-pass produces byte-identical Property nodes/symbols
+// to the worker pool. Drift between the two paths breaks the
+// `incremental ≡ --force` invariant the moment a repo crosses the worker
+// threshold between runs.
+/** Walk up to the nearest enclosing class/struct/interface AST node. */
+const findEnclosingClassNode = (node) => {
+    let current = node.parent;
+    while (current) {
+        if (CLASS_CONTAINER_TYPES.has(current.type))
+            return current;
+        current = current.parent;
+    }
+    return null;
+};
+/** No-op SymbolTable stub for FieldExtractorContext — matches parse-worker. */
+const NOOP_SYMBOL_TABLE = {
+    lookupExact: () => undefined,
+    lookupExactFull: () => undefined,
+    lookupExactAll: () => [],
+    lookupCallableByName: () => [],
+    getFiles: () => [][Symbol.iterator](),
+    getStats: () => ({ fileCount: 0 }),
+};
+/**
+ * Extract (and cache) field info for a class node. Cache is passed in so it
+ * stays scoped to a single `processCalls` invocation rather than leaking
+ * across analyze runs (worker uses module-level caching because each worker
+ * process is short-lived; the main thread is not).
+ *
+ * Cache key is `${filePath}:${classNode.startIndex}` — startIndex alone is a
+ * per-file byte offset, so almost every Ruby/Python file's leading class lands
+ * at byte 0 and would collide across files in the shared map.
+ */
+const getFieldInfo = (classNode, provider, context, cache) => {
+    if (!provider.fieldExtractor)
+        return undefined;
+    const cacheKey = `${context.filePath}:${classNode.startIndex}`;
+    const cached = cache.get(cacheKey);
+    if (cached)
+        return cached;
+    const result = provider.fieldExtractor.extract(classNode, context);
+    if (!result?.fields?.length)
+        return undefined;
+    const map = new Map();
+    for (const field of result.fields)
+        map.set(field.name, field);
+    cache.set(cacheKey, map);
+    return map;
+};
 /**
  * Type labels treated as class-like **method-dispatch receivers** by the call
  * resolver — the set walked by the MRO / heritage path for member and static
@@ -702,6 +753,111 @@ importedRawReturnTypesMap, heritageMap, bindingAccumulator) => {
         }
         prepared.push({ file, language, provider, tree, matches, parentMap, typeEnv });
     }
+    // ── Property-registration pre-pass ──
+    // Register all routed properties (e.g. Ruby attr_accessor) BEFORE the
+    // resolution loop so cross-file field-type lookups (e.g.
+    // `user.address.save → Address#save`) succeed regardless of file
+    // processing order. This MUST stay in lockstep with the equivalent
+    // worker-path block in parse-worker.ts (kind === 'properties') — any
+    // divergence between the two paths breaks the `incremental ≡ --force`
+    // invariant once a repo crosses the worker threshold between runs.
+    const fieldInfoCache = new Map();
+    for (const { file, language, provider, matches, typeEnv } of prepared) {
+        const callRouter = provider.callRouter;
+        if (!callRouter)
+            continue;
+        matches.forEach((match) => {
+            const captureMap = {};
+            match.captures.forEach((c) => (captureMap[c.name] = c.node));
+            if (!captureMap['call'])
+                return;
+            const callNameNode = captureMap['call.name'];
+            if (!callNameNode)
+                return;
+            const routed = callRouter(callNameNode.text, captureMap['call']);
+            if (!routed || routed.kind !== 'properties')
+                return;
+            const propEnclosingInfo = findEnclosingClassInfo(captureMap['call'], file.path, provider.resolveEnclosingOwner);
+            const propEnclosingClassId = propEnclosingInfo?.classId ?? null;
+            // Enrich routed properties with FieldExtractor metadata so types
+            // discovered from constructor assignments (e.g. `@address = Address.new`)
+            // are propagated even when the routing payload itself lacks declaredType.
+            let routedFieldMap;
+            if (provider.fieldExtractor && typeEnv) {
+                const classNode = findEnclosingClassNode(captureMap['call']);
+                if (classNode) {
+                    routedFieldMap = getFieldInfo(classNode, provider, {
+                        typeEnv,
+                        symbolTable: NOOP_SYMBOL_TABLE,
+                        filePath: file.path,
+                        language,
+                    }, fieldInfoCache);
+                }
+            }
+            const fileId = generateId('File', file.path);
+            for (const item of routed.items) {
+                const routedFieldInfo = routedFieldMap?.get(item.propName);
+                const propQualifiedName = propEnclosingInfo
+                    ? `${propEnclosingInfo.className}.${item.propName}`
+                    : item.propName;
+                const nodeId = generateId('Property', `${file.path}:${propQualifiedName}`);
+                graph.addNode({
+                    id: nodeId,
+                    label: 'Property',
+                    properties: {
+                        name: item.propName,
+                        filePath: file.path,
+                        startLine: item.startLine,
+                        endLine: item.endLine,
+                        language,
+                        isExported: true,
+                        description: item.accessorType,
+                        ...(item.declaredType
+                            ? { declaredType: item.declaredType }
+                            : routedFieldInfo?.type
+                                ? { declaredType: routedFieldInfo.type }
+                                : {}),
+                        ...(routedFieldInfo?.visibility !== undefined
+                            ? { visibility: routedFieldInfo.visibility }
+                            : {}),
+                        ...(routedFieldInfo?.isStatic !== undefined
+                            ? { isStatic: routedFieldInfo.isStatic }
+                            : {}),
+                        ...(routedFieldInfo?.isReadonly !== undefined
+                            ? { isReadonly: routedFieldInfo.isReadonly }
+                            : {}),
+                    },
+                });
+                ctx.model.symbols.add(file.path, item.propName, nodeId, 'Property', {
+                    ...(propEnclosingClassId ? { ownerId: propEnclosingClassId } : {}),
+                    ...(item.declaredType
+                        ? { declaredType: item.declaredType }
+                        : routedFieldInfo?.type
+                            ? { declaredType: routedFieldInfo.type }
+                            : {}),
+                });
+                const relId = generateId('DEFINES', `${fileId}->${nodeId}`);
+                graph.addRelationship({
+                    id: relId,
+                    sourceId: fileId,
+                    targetId: nodeId,
+                    type: 'DEFINES',
+                    confidence: 1.0,
+                    reason: '',
+                });
+                if (propEnclosingClassId) {
+                    graph.addRelationship({
+                        id: generateId('HAS_PROPERTY', `${propEnclosingClassId}->${nodeId}`),
+                        sourceId: propEnclosingClassId,
+                        targetId: nodeId,
+                        type: 'HAS_PROPERTY',
+                        confidence: 1.0,
+                        reason: '',
+                    });
+                }
+            }
+        });
+    }
     // ── Resolution loop: verify constructor bindings and resolve calls ──
     // The accumulator (if present) is now fully populated from the preparation
     // loop above, so verifyConstructorBindings sees all provider bindings
@@ -750,9 +906,10 @@ importedRawReturnTypesMap, heritageMap, bindingAccumulator) => {
                 if (receiverTypeName) {
                     const enclosing = findEnclosingFunction(captureMap['assignment'], file.path, ctx, provider);
                     const srcId = enclosing || generateId('File', file.path);
-                    // Defer resolution: Ruby attr_accessor properties are registered during
-                    // this same loop, so cross-file lookups fail if the declaring file hasn't
-                    // been processed yet. Collect now, resolve after all files are done.
+                    // Defer resolution so write-access tracking sees the FINAL graph
+                    // state — properties from the pre-pass are present, but receiver-type
+                    // resolution can still depend on inference that completes during the
+                    // main loop. Resolve after all files have been processed.
                     pendingWrites.push({ receiverTypeName, propertyName, filePath: file.path, srcId });
                 }
                 // Assignment-only capture (no @call sibling): skip the rest of this
@@ -842,47 +999,8 @@ importedRawReturnTypesMap, heritageMap, bindingAccumulator) => {
                     case 'import':
                         return;
                     case 'properties': {
-                        const fileId = generateId('File', file.path);
-                        const propEnclosingClassId = findEnclosingClassId(captureMap['call'], file.path);
-                        for (const item of routed.items) {
-                            const nodeId = generateId('Property', `${file.path}:${item.propName}`);
-                            graph.addNode({
-                                id: nodeId,
-                                label: 'Property',
-                                properties: {
-                                    name: item.propName,
-                                    filePath: file.path,
-                                    startLine: item.startLine,
-                                    endLine: item.endLine,
-                                    language,
-                                    isExported: true,
-                                    description: item.accessorType,
-                                },
-                            });
-                            ctx.model.symbols.add(file.path, item.propName, nodeId, 'Property', {
-                                ...(propEnclosingClassId ? { ownerId: propEnclosingClassId } : {}),
-                                ...(item.declaredType ? { declaredType: item.declaredType } : {}),
-                            });
-                            const relId = generateId('DEFINES', `${fileId}->${nodeId}`);
-                            graph.addRelationship({
-                                id: relId,
-                                sourceId: fileId,
-                                targetId: nodeId,
-                                type: 'DEFINES',
-                                confidence: 1.0,
-                                reason: '',
-                            });
-                            if (propEnclosingClassId) {
-                                graph.addRelationship({
-                                    id: generateId('HAS_PROPERTY', `${propEnclosingClassId}->${nodeId}`),
-                                    sourceId: propEnclosingClassId,
-                                    targetId: nodeId,
-                                    type: 'HAS_PROPERTY',
-                                    confidence: 1.0,
-                                    reason: '',
-                                });
-                            }
-                        }
+                        // Properties already registered in the pre-pass above.
+                        // Skip to avoid duplicate nodes/edges.
                         return;
                     }
                     case 'call':

package/dist/core/ingestion/community-processor.js

@@ -20,6 +20,23 @@ const __dirname = dirname(__filename);
 const leidenPath = resolve(__dirname, '..', '..', '..', 'vendor', 'leiden', 'index.cjs');
 const _require = createRequire(import.meta.url);
 const leiden = _require(leidenPath);
+/**
+ * Deterministic PRNG (mulberry32) seed for the vendored Leiden algorithm.
+ * Vendored Leiden defaults `rng: Math.random`, which makes community
+ * assignment non-deterministic across runs. Passing a seeded RNG gives us
+ * reproducible community/modularity output, which is required for the
+ * incremental-indexing equivalence test (incremental ≡ full rebuild).
+ */
+const LEIDEN_SEED = 0xc0de;
+function createSeededRng(seed) {
+    let s = seed >>> 0;
+    return () => {
+        s = (s + 0x6d2b79f5) >>> 0;
+        let t = Math.imul(s ^ (s >>> 15), 1 | s);
+        t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
+        return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
+    };
+}
 // ============================================================================
 // COMMUNITY COLORS (for visualization)
 // ============================================================================
@@ -83,6 +100,7 @@ export const processCommunities = async (knowledgeGraph, onProgress) => {
             Promise.resolve(leiden.detailed(graph, {
                 resolution: isLarge ? 2.0 : 1.0,
                 maxIterations: isLarge ? 3 : 0,
+                rng: createSeededRng(LEIDEN_SEED),
             })),
             new Promise((_, reject) => setTimeout(() => reject(new Error('Leiden timeout')), LEIDEN_TIMEOUT_MS)),
         ]);

package/dist/core/ingestion/languages/java/arity-metadata.d.ts

@@ -0,0 +1,18 @@
+/**
+ * Extract Java arity metadata from a method-like tree-sitter node —
+ * `method_declaration` or `constructor_declaration`.
+ *
+ * Reuses `javaMethodConfig.extractParameters` so scope-extracted defs
+ * carry the same arity semantics as the legacy parse-worker path:
+ *   - varargs (`...`) collapses `parameterCount` to `undefined`
+ *   - `parameterTypes` collects declared type names; a literal
+ *     `'varargs'` marker is appended for variadic methods so
+ *     `javaArityCompatibility` can detect them.
+ */
+import type { SyntaxNode } from '../../utils/ast-helpers.js';
+export interface JavaArityMetadata {
+    readonly parameterCount: number | undefined;
+    readonly requiredParameterCount: number | undefined;
+    readonly parameterTypes: readonly string[] | undefined;
+}
+export declare function computeJavaArityMetadata(fnNode: SyntaxNode): JavaArityMetadata;

package/dist/core/ingestion/languages/java/arity-metadata.js

@@ -0,0 +1,40 @@
+/**
+ * Extract Java arity metadata from a method-like tree-sitter node —
+ * `method_declaration` or `constructor_declaration`.
+ *
+ * Reuses `javaMethodConfig.extractParameters` so scope-extracted defs
+ * carry the same arity semantics as the legacy parse-worker path:
+ *   - varargs (`...`) collapses `parameterCount` to `undefined`
+ *   - `parameterTypes` collects declared type names; a literal
+ *     `'varargs'` marker is appended for variadic methods so
+ *     `javaArityCompatibility` can detect them.
+ */
+import { javaMethodConfig } from '../../method-extractors/configs/jvm.js';
+export function computeJavaArityMetadata(fnNode) {
+    const params = javaMethodConfig.extractParameters?.(fnNode) ?? [];
+    let hasVariadic = false;
+    const types = [];
+    for (const p of params) {
+        if (p.isVariadic)
+            hasVariadic = true;
+        if (p.type !== null)
+            types.push(p.type);
+    }
+    if (hasVariadic)
+        types.push('varargs');
+    const total = params.length;
+    // For varargs methods, `parameterCount` (max) is unknown — any number of
+    // trailing arguments is valid.  But the fixed-prefix parameters (everything
+    // before the variadic `...` param) are still required, so we preserve that
+    // count in `requiredParameterCount` so `javaArityCompatibility` can reject
+    // calls that undersupply the fixed prefix (e.g. `f(int x, String... args)`
+    // called with 0 args).
+    const fixedCount = params.filter((p) => !p.isVariadic).length;
+    const parameterCount = hasVariadic ? undefined : total;
+    const requiredParameterCount = hasVariadic ? fixedCount : total;
+    return {
+        parameterCount,
+        requiredParameterCount,
+        parameterTypes: types.length > 0 ? types : undefined,
+    };
+}

package/dist/core/ingestion/languages/java/arity.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Java arity check, accommodating varargs (`...`).
+ *
+ * Verdicts:
+ *   - `'compatible'`   — argCount matches parameterCount, OR varargs present.
+ *   - `'incompatible'` — argCount mismatches with no varargs.
+ *   - `'unknown'`      — metadata absent / incomplete.
+ */
+import type { Callsite, SymbolDefinition } from '../../../../_shared/index.js';
+export declare function javaArityCompatibility(def: SymbolDefinition, callsite: Callsite): 'compatible' | 'unknown' | 'incompatible';

package/dist/core/ingestion/languages/java/arity.js

@@ -0,0 +1,24 @@
+/**
+ * Java arity check, accommodating varargs (`...`).
+ *
+ * Verdicts:
+ *   - `'compatible'`   — argCount matches parameterCount, OR varargs present.
+ *   - `'incompatible'` — argCount mismatches with no varargs.
+ *   - `'unknown'`      — metadata absent / incomplete.
+ */
+export function javaArityCompatibility(def, callsite) {
+    const max = def.parameterCount;
+    const min = def.requiredParameterCount;
+    if (max === undefined && min === undefined)
+        return 'unknown';
+    const argCount = callsite.arity;
+    if (!Number.isFinite(argCount) || argCount < 0)
+        return 'unknown';
+    const hasVarArgs = def.parameterTypes !== undefined &&
+        def.parameterTypes.some((t) => t === 'varargs' || t.includes('...'));
+    if (min !== undefined && argCount < min)
+        return 'incompatible';
+    if (max !== undefined && argCount > max && !hasVarArgs)
+        return 'incompatible';
+    return 'compatible';
+}