Rust workspace composition

Treat the resolved dependency/feature graph and public crate surface as the unit of evidence. A workspace may have one or many members; its usefulness depends on the project.

Work from the affected contract

1. Inspect members, resolver, dependency/feature graph, toolchain and publishing intent. Preserve current crate boundaries unless evidence motivates a structural change.
2. Check workspace dependency/lint inheritance and allowed exceptions. Compare selected-package and whole-workspace feature builds where unification may hide a missing production dependency.
3. Trace public/internal type exposure and dependency direction. Keep private crates private; document semver impact before altering exported traits or re-exports.
4. Select test, coverage and Miri targets for actual platform/FFI constraints. Preserve per-crate visibility rather than trusting only an aggregate coverage number.
5. For release, verify dependency order, version policy, dry-run packaging and consumer compatibility. Record command results and excluded target/feature cases.

Scope and completion

A local feature or policy repair needs a focused note/diff and checks, not thirteen new design files. For a new workspace, use the existing tiered design references as needed. Crate splitting, task runners and single-member workspaces are choices to justify, not mandatory patterns or automatic defects.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references