Module dependent_version_states 

Every workspace manifest at both states, and which versions were raised. What: Read every workspace manifest at the candidate state and at the base, and decide which packages’ versions were raised. Why: The plan starts from these facts. The order of failures follows the incumbent’s: every manifest is decoded before any is parsed (its reader decodes while listing, dependent-version-bump-policy.ts:82-92), and each manifest’s base text is parsed before its current text (dependent-bump-workflow.ts:150-174).

In TS you’d write (pseudocode):

// const states = (await reader.manifests()).map(readManifestState);

Structs

ManifestState

What: One workspace manifest with what the plan needs from it. Why: The patch is built from the exact current bytes; the text after an optional byte-order mark is what was parsed and what the version edit rewrites.

Functions

bumped_names

What: The names of packages whose version differs from the base, in manifest order. Why: A manifest new at this state, or without a version at the base, raised nothing; a version removed at this state counts as raised, as in the incumbent.

duplicate_name

What: The first pair of manifests, in order, that declare the same package name. Why: With two packages of one name, a dependency edge cannot say which it means; the planner refuses rather than choosing one.

read_manifest_states

What: Read and decode every workspace manifest, then parse each, base first. &mut dyn WorkspaceContent lends any provider for writing; ? returns a failure to the caller. Why: A malformed manifest at either state stops the plan, as in the incumbent.