Context
Follow-up from #84 / #91. Incremental reindexing is wired only into load_or_build_index (the global ~/.csp/index/ cache path used by csp search and the MCP server). Two other build entry points still do a full rebuild every time:
csp index -o <dir> (explicit output dir) writes a manifest with files but never seeds from it.
- The napi SDK
CspIndex.fromPath / loadFromDisk in crates/csp-node never calls load_previous_for_incremental.
Proposal
csp index -o: when <dir>/manifest.json exists and is compatible, pass it as previous to from_path_with_previous.
- SDK: expose the same behaviour via
fromPath(path, { indexDir }) or an explicit reindex(indexDir).
Acceptance
- CLI test in
crates/csp/tests proving a second csp index -o reuses unchanged files (sentinel chunk survives, as in load_or_build_reuses_unchanged_files_on_incremental_rebuild).
- SDK type surface (
index.d.ts) updated; README (both languages) mentions it.
Context
Follow-up from #84 / #91. Incremental reindexing is wired only into
load_or_build_index(the global~/.csp/index/cache path used bycsp searchand the MCP server). Two other build entry points still do a full rebuild every time:csp index -o <dir>(explicit output dir) writes a manifest withfilesbut never seeds from it.CspIndex.fromPath/loadFromDiskincrates/csp-nodenever callsload_previous_for_incremental.Proposal
csp index -o: when<dir>/manifest.jsonexists and is compatible, pass it asprevioustofrom_path_with_previous.fromPath(path, { indexDir })or an explicitreindex(indexDir).Acceptance
crates/csp/testsproving a secondcsp index -oreuses unchanged files (sentinel chunk survives, as inload_or_build_reuses_unchanged_files_on_incremental_rebuild).index.d.ts) updated; README (both languages) mentions it.