Module dependent_version_lifecycle 

The dependent-version planner’s view of a prepared candidate state. What: The dependent-version planner’s view of a prepared candidate state: every tracked file of the private index, its bytes with this invocation’s corrections laid over them, and the HEAD commit’s copy of a file. Why: The planner reads workspace manifests, the registry configuration and source files wherever they are, not only the candidates; the installed wrapper’s policy reads them as tracked files of the candidate state (trackedFiles, bytes, headBytes). Everything goes through the store the candidates were prepared in, so a direct fix’s later pass reads what its earlier passes corrected.

In TS you’d write (pseudocode):

// const workspace = lifecycleWorkspace(store, corrected, candidatePaths); await planWorkspaceBumps(workspace);

Structs

LifecycleWorkspace

What: The candidate state as the planner reads it. 'a names how long the borrows of the store, the corrections and the candidate paths last. Why: Both listings are read once, when first needed, and kept as versions of the store’s current generation, whose bytes the store reads.

Functions

lifecycle_workspace

What: A view over a prepared store. candidates are the lifecycle’s candidate paths that are not deletions. Why: Nothing is listed until the planner asks.

tracked_mode

What: The planner’s mode for a candidate mode. Why: The two enumerations name the same four Git modes.