What happened
In the `fixer-run` worktree (branch `fix/issue-2560`, HEAD `874a94c4`), `codegraph stats` reported:
```
Nodes: 21937 total
parameter 8858 method 5198 function 4317 file 1099 constant 997
interface 840 property 222 class 201 type 107 ...
Edges: 29694 total
contains 20836 parameter_of 8858
Only \`contains\` and \`parameter_of\` edges existed — zero \`calls\`, \`imports\`, \`imports-type\`, \`extends\`, \`implements\`, \`receiver\`, \`reexports\`, or \`dynamic-imports\` edges, across the full 1099-file / 34-language repo.
Running the default incremental build against this exact tree:
\`\`\`
$ node dist/cli.js build
[codegraph] Using native engine (v3.16.0)
[codegraph] Found 1099 files to parse
[codegraph] No changes detected
— it declared the graph up to date and did nothing.
Forcing a full rebuild on the identical source tree (`--no-incremental`) produced a very different, and clearly more correct, result:
```
$ node dist/cli.js build --no-incremental
[codegraph] Native build orchestrator completed: 23028 nodes, 49652 edges, 1099 files
\`\`\`
Edges: 49652 total
contains 23022 calls 10689 parameter_of 8858 receiver 2738
imports 2136 imports-type 1392 reexports 633 dynamic-imports 116
extends 45 implements 21 reexports-wildcard 2
Node-kind distribution also shifted substantially between the two runs (e.g. `method` 5198→1154, `property` 222→4280, `constant` 997→1848), suggesting the stale `graph.db` predates several extraction-logic changes, not just a few edited files.
Why this matters
The incremental path's change-detection (file-hash based, in `domain/graph/builder.ts`) is supposed to guarantee the graph reflects the current source tree, or trigger a rebuild of whatever changed. Here it concluded "no changes" against a database that a full rebuild showed to be missing ~40% of edge categories entirely. That's a silent correctness gap: anyone trusting `codegraph build` (not `--no-incremental`) in a long-lived worktree could be querying/analyzing a graph that looks complete (populated `stats` output, no errors) but is actually missing most call/import/inheritance edges.
`npm run doctor` passed clean (native binary loads fine, ABI OK, no stale-binary warning) — this isn't the already-known stale-native-binary class of issue.
Repro environment
- Worktree reused across many sequential issue branches (the `/fixer` skill's pattern of running many issues through one worktree over time) — likely relevant, since this is exactly the scenario where incremental hash tracking needs to correctly invalidate across many branch switches / merges.
- `codegraph build` reports `Using native engine (v3.16.0)` while `package.json` is at `3.17.0` — noting this version delta in case it's relevant to root cause, though `npm run doctor` did not flag it as an ABI staleness problem.
Ask
Root-cause why the incremental build's staleness detection (file-hash / journal logic in `domain/graph/builder.ts` and `domain/graph/journal.ts`) let the graph drift this far from a full-rebuild result without ever deciding a rebuild was needed. The incremental path should never be able to silently leave the graph in a state this incomplete relative to what a full rebuild of the identical tree produces.
What happened
In the `fixer-run` worktree (branch `fix/issue-2560`, HEAD `874a94c4`), `codegraph stats` reported:
```
Nodes: 21937 total
parameter 8858 method 5198 function 4317 file 1099 constant 997
interface 840 property 222 class 201 type 107 ...
Edges: 29694 total
contains 20836 parameter_of 8858
— it declared the graph up to date and did nothing.
Forcing a full rebuild on the identical source tree (`--no-incremental`) produced a very different, and clearly more correct, result:
```
$ node dist/cli.js build --no-incremental
[codegraph] Native build orchestrator completed: 23028 nodes, 49652 edges, 1099 files
Node-kind distribution also shifted substantially between the two runs (e.g. `method` 5198→1154, `property` 222→4280, `constant` 997→1848), suggesting the stale `graph.db` predates several extraction-logic changes, not just a few edited files.
Why this matters
The incremental path's change-detection (file-hash based, in `domain/graph/builder.ts`) is supposed to guarantee the graph reflects the current source tree, or trigger a rebuild of whatever changed. Here it concluded "no changes" against a database that a full rebuild showed to be missing ~40% of edge categories entirely. That's a silent correctness gap: anyone trusting `codegraph build` (not `--no-incremental`) in a long-lived worktree could be querying/analyzing a graph that looks complete (populated `stats` output, no errors) but is actually missing most call/import/inheritance edges.
`npm run doctor` passed clean (native binary loads fine, ABI OK, no stale-binary warning) — this isn't the already-known stale-native-binary class of issue.
Repro environment
Ask
Root-cause why the incremental build's staleness detection (file-hash / journal logic in `domain/graph/builder.ts` and `domain/graph/journal.ts`) let the graph drift this far from a full-rebuild result without ever deciding a rebuild was needed. The incremental path should never be able to silently leave the graph in a state this incomplete relative to what a full rebuild of the identical tree produces.