Rust Crate Design

Use this when the hard part is where a Rust responsibility should live, not how to write the next function.

Working stance

• Keep domain logic away from IO, framework glue, and process setup.
• Public crates should expose stable concepts, not convenience shortcuts.
• Prefer thin binaries and reusable libraries.
• Add a workspace only when multiple crates truly need shared versioning, dependency policy, lints, or release choreography.
• Feature flags should add integration or optional capability, not split core behaviour into incompatible worlds.
• Tests should follow the same boundaries the design claims to have.

Decision surface