[boris-virto]

The emitted SQL opens with DELETE FROM documents WHERE repo = , and chunks cascade off documents. Chunks carry the embeddings, so editing one file and re-ingesting recomputes the entire corpus: on a 127-document set that is ~75 s of bge-m3 for a change worth two chunks. On anything larger it makes a routine refresh impractical, which pushes people towards not refreshing -- and a stale corpus fails silently, by answering from old text.

documents.content_hash is already NOT NULL and written on every insert, but nothing reads it. This makes it load-bearing: pass --known-hashes with a path<TAB>hash TSV of what the DB holds and the ingester emits only new and changed documents, deletes changed and vanished ones by path, and leaves everything else -- chunks, embeddings, constraint links -- alone.

Deliberately kept DB-free. The ingester still just writes a .sql file, because INSTALL.md's Kubernetes path depends on that (the store is not reachable from the laptop; the SQL is carried in). The diff input arrives as a file the operator produces however they can reach the store, so the incremental path works over kubectl exec and tunnels like everything else.

Two interactions worth naming:

• ci/freshness.py counts documents whose git_commit != HEAD as stale, and --mark writes status='stale'. Skipping unchanged rows would leave them at their old commit and report the whole corpus as stale after any commit. The incremental header refreshes git_commit for the repo first: the content IS current as of this commit, only the chunks were not rewritten.
• Without --known-hashes the emitted SQL is byte-identical to before (verified by diffing the output of both versions over this repo), so existing callers are untouched.

tests/test_incremental_ingest.py pins the contract from the outside, DB-free, and is wired into CI. It asserts the negatives that have no other symptom: no blanket DELETE, the unchanged document absent from the output, the changed and vanished ones inside the DELETE list, and the git_commit refresh present. A silent regression to full-replace would still produce a correct corpus -- it would only cost every embedding, which reads as "embedding is slow", so nothing else in CI would notice.