feat: add --incremental flag to analyze command

[zenprocess]

Summary

Adds an --incremental flag to the analyze command that skips re-parsing unchanged files on subsequent runs. This dramatically reduces re-index time for large repos when only a few files changed.

How it works

1. During indexing, computes SHA-256 hashes for every parsed file
2. Stores hashes in meta.json alongside the existing repo metadata
3. On subsequent runs with --incremental, compares current hashes against stored ones
4. Only files with changed hashes are re-parsed — structure scanning and graph phases still run fully to ensure correct community/process detection
5. Stale nodes (from deleted/renamed files) are removed from LadybugDB instead of wiping and recreating

Performance

For a 60K+ symbol TypeScript repo, re-index time drops from ~30s to ~2-5s when only a few files changed between runs.

Usage

gitnexus analyze /path/to/repo                # full index (default)
gitnexus analyze -i /path/to/repo             # incremental (skip unchanged)
gitnexus analyze --incremental /path/to/repo  # same

Docker:

docker run -e GITNEXUS_INCREMENTAL=1 ...      # enables --incremental on container restart

Files changed

File	Change
src/storage/file-hasher.ts	NEW — computeFileHashes() and diffFileHashes()
src/cli/index.ts	Register -i/--incremental CLI flag
src/cli/analyze.ts	Forward incremental option to runFullAnalysis
src/core/run-analyze.ts	Load previous hashes, pass to pipeline, save new hashes, incremental LadybugDB merge
src/core/ingestion/pipeline.ts	Accept previousFileHashes, filter parse phase to changed files only, return fileHashes in result
src/types/pipeline.ts	Add fileHashes to PipelineResult
src/storage/repo-manager.ts	Add fileHashes to RepoMeta
Dockerfile	Production two-stage build with incremental support
entrypoint.sh	Container entrypoint — indexes repos, starts eval-server

Test plan

• gitnexus analyze /path/to/repo produces same graph as before (no regression)
• gitnexus analyze -i /path/to/repo on second run skips unchanged files (check console output: "Incremental: N changed, M removed, K unchanged")
• Deleting a source file and re-running with -i removes stale nodes from the graph
• Adding a new file and re-running with -i indexes only the new file
• meta.json contains fileHashes after first run

[vercel]

@TESTPERSONAL is attempting to deploy a commit to the NexusCore Team on Vercel.

A member of the Team first needs to authorize it.

[xkonjin]

Code Review — Incremental Analyze

Overall: Well-structured feature, one blocking bug 🟡

The SHA-256 file hashing + diff approach for incremental indexing is clean and the batched I/O (100 files at a time) avoids fd exhaustion. The Docker + entrypoint additions look solid.

Positives

• file-hasher.ts is well-isolated and testable. Clean separation of computeFileHashes and diffFileHashes.
• The merged-hash logic in run-analyze.ts correctly maintains the full hash map across incremental runs.
• Docker entrypoint auto-detects empty registry and falls back to --force, which is good UX.

Issues

1. 🔴 Missing export: deleteNodesForFile not in lbug-adapter.ts
run-analyze.ts imports deleteNodesForFile from ./lbug/lbug-adapter.js, but this function does not exist in that module. It exists in kuzu-adapter.ts. This will cause a runtime import error when incremental mode tries to delete stale nodes. Either re-export it from lbug-adapter or change the import path.

2. 🟡 Hash merge uses (pipelineResult as any).fileHashes cast
Line ~210 in run-analyze.ts mutates the pipeline result via as any cast. Consider adding fileHashes as a mutable field on the result type, or returning the merged hashes separately to avoid the type escape hatch.

3. 🟡 No tests for file-hasher.ts
The new module has no accompanying tests. At minimum, diffFileHashes deserves unit tests for the three cases: all new files, mixed changed/unchanged/removed, and no previous hashes.

4. (nit) Entrypoint $GITNEXUS_INCREMENTAL env var is undocumented
The Docker entrypoint checks GITNEXUS_INCREMENTAL=1 but this is not mentioned in any README or Dockerfile comment.

Verdict

The import bug (#1) will cause a runtime crash in incremental mode and needs fixing before merge. The rest is solid work.

[magyargergo]

Please submit a new PR if this is still relevant

[vvladescu-tb]

Thanks for the nudge @magyargergo. This PR is superseded by #1479 (your own incremental-indexing branch), which we're already pinning at 42302bc7 and running in production against several repos.

Two companion PRs incoming from us:

1. Tests-only PR against feat/incremental-indexing — 212 lines of unit tests covering parse-cache fingerprinting + subgraph extraction (none of which exist in feat(analyze): incremental indexing (parse cache + DB writeback + scope-res short-circuit) #1479 today). Addresses your "look into Claude's findings" review-feedback on feat(analyze): incremental indexing (parse cache + DB writeback + scope-res short-circuit) #1479 from a test-coverage angle.
2. Issue proposing POST /reindex on eval-server — daemon consumers currently have no way to trigger an incremental re-analyze through the HTTP API; we orchestrate by spawning gitnexus analyze subprocesses. A daemon-side endpoint that wraps run-analyze + hot-swaps the LadybugDB handle would make incremental usable for the running-server use case.

Closing this in favor of those.