Module candidate_store 

Per-invocation listing, lazy bytes and invalidation of candidate versions. What: The per-invocation owner of candidate versions and candidate bytes. Why: Policies read committed or staged content, never whatever is in the live worktree. A version costs one listing process, its bytes come from one long-lived object reader, and neither count grows with the number of files. After a fix or replay changed the index, invalidate retires every version.

In TS you’d write (pseudocode):

// const store = new CandidateStore(git, prefix, overlay);
// const version = await store.version({ kind: 'staged-against-head' });
// const bytes = await store.bytes(version.candidates[0]);

Structs

CandidateStore

What: Everything one invocation needs to list and read candidates. Option<ObjectReader> is “a running reader or nothing”; u64 is an unsigned 64-bit counter (siblings u32, usize). Why: The reader is started only when something needs it, so an invocation that reads no object starts no reader. u64 cannot run out within a process.