Summary
codegraph deps <f> / codegraph where --file <f> reported 5 import edges for src/presentation/audit.ts, but the file currently has only 3 imports. This is not an "unbuilt/stale graph, needs rebuild" situation in the usual sense — the file_hashes table's stored hash for this file exactly matches the current on-disk content's sha256, yet the edges table still holds 2 additional imports rows that don't exist in the current source. So the incremental build is treating the file as unchanged (correctly, by hash) while simultaneously holding edge data from a prior version of the file — i.e. hash-based change-detection and edge data are out of sync with each other for this node.
Repro (this worktree, .codegraph/graph.db)
$ grep -n "^import" src/presentation/audit.ts
1:import { kindIcon } from '../domain/queries.js';
2:import { auditData } from '../features/audit.js';
3:import { outputResult } from '../infrastructure/result-formatter.js';
$ shasum -a 256 src/presentation/audit.ts
10dd48dbd0bb9706e576f0b806ee17f03f8d50a0587115a99f1693887bfc8e42 src/presentation/audit.ts
$ sqlite3 .codegraph/graph.db "SELECT * FROM file_hashes WHERE file='src/presentation/audit.ts';"
src/presentation/audit.ts|10dd48dbd0bb9706e576f0b806ee17f03f8d50a0587115a99f1693887bfc8e42|1782970911441|3572
$ sqlite3 -header -column .codegraph/graph.db "
SELECT e.id, n1.file as src_file, n2.file as target_file, e.kind
FROM edges e JOIN nodes n1 ON e.source_id=n1.id JOIN nodes n2 ON e.target_id=n2.id
WHERE n1.file='src/presentation/audit.ts' AND e.kind='imports';"
id src_file target_file kind
62952 src/presentation/audit.ts src/domain/queries.ts imports
62953 src/presentation/audit.ts src/shared/normalize.ts imports
62954 src/presentation/audit.ts src/features/audit.ts imports
62955 src/presentation/audit.ts src/infrastructure/result-formatter.ts imports
62956 src/presentation/audit.ts src/presentation/result-formatter.ts imports
The stored file_hashes sha256 for the file is byte-identical to the current file's sha256 — so this isn't the ordinary "edit a file, forget to rebuild" case where a mismatched hash would correctly trigger a re-parse. Something updated (or left) the hash correctly while the edge rows from an older version of the file (which apparently imported shared/normalize.ts and presentation/result-formatter.ts too) were never purged/regenerated.
Impact
codegraph deps/codegraph where --file cannot be trusted for dependency-direction / architecture-boundary auditing even against a graph whose file_hashes claims to be current — the standard "is the graph stale, do I need to rebuild" check (compare stored hash to file content) is not sufficient to guarantee edge correctness for every node.
Expected
If a file's edges are ever regenerated, they should always correspond to the same content revision reflected in file_hashes for that file — either both are updated together, or neither is until a full re-parse of that file completes.
Context
Found while running the Titan GAUNTLET quality-audit pass (/titan-gauntlet) over src/presentation/audit.ts, in a worktree at HEAD 597ed1c3036ebb2c5f6fe457be9d156bdf33d273 (codegraph v3.15.0). Have not root-caused which prior operation (incremental build path, snapshot restore, etc.) left the edges stale; flagging with a concrete, reproducible repro for the maintainers to trace further.
Summary
codegraph deps <f>/codegraph where --file <f>reported 5 import edges forsrc/presentation/audit.ts, but the file currently has only 3 imports. This is not an "unbuilt/stale graph, needs rebuild" situation in the usual sense — thefile_hashestable's stored hash for this file exactly matches the current on-disk content's sha256, yet theedgestable still holds 2 additionalimportsrows that don't exist in the current source. So the incremental build is treating the file as unchanged (correctly, by hash) while simultaneously holding edge data from a prior version of the file — i.e. hash-based change-detection and edge data are out of sync with each other for this node.Repro (this worktree,
.codegraph/graph.db)The stored
file_hashessha256 for the file is byte-identical to the current file's sha256 — so this isn't the ordinary "edit a file, forget to rebuild" case where a mismatched hash would correctly trigger a re-parse. Something updated (or left) the hash correctly while the edge rows from an older version of the file (which apparently importedshared/normalize.tsandpresentation/result-formatter.tstoo) were never purged/regenerated.Impact
codegraph deps/codegraph where --filecannot be trusted for dependency-direction / architecture-boundary auditing even against a graph whosefile_hashesclaims to be current — the standard "is the graph stale, do I need to rebuild" check (compare stored hash to file content) is not sufficient to guarantee edge correctness for every node.Expected
If a file's edges are ever regenerated, they should always correspond to the same content revision reflected in
file_hashesfor that file — either both are updated together, or neither is until a full re-parse of that file completes.Context
Found while running the Titan GAUNTLET quality-audit pass (
/titan-gauntlet) oversrc/presentation/audit.ts, in a worktree at HEAD597ed1c3036ebb2c5f6fe457be9d156bdf33d273(codegraph v3.15.0). Have not root-caused which prior operation (incremental build path, snapshot restore, etc.) left the edges stale; flagging with a concrete, reproducible repro for the maintainers to trace further.