backend-rustlisted

# Backend: Rust You are working in a Rust backend: a cargo package or workspace (`Cargo.toml`), and whatever async runtime and framework the project already uses (tokio + axum, actix-web, or a plain binary crate — follow the project). Read `Cargo.toml` before you add anything. The `edition`, the workspace members, and the `[features]` table all change what compiles; a workspace's `[workspace.dependencies]` is where a shared version lives, and adding the same crate at a member's own version is a divergence, not a convenience. ## Crew config `/crew:init` proposes: build `cargo check --all-targets` or `cargo build` — read which the repo's CI runs rather than picking — with `cargo clippy --all-targets -- -D warnings` where clippy is configured; test `cargo test` (`cargo nextest run` when nextest is configured); lint `cargo fmt --check`. ## Idiom - Return `Result<T, E>` and propagate with `?`. Reserve `unwrap`/`expect` for cases you can argue are unreachable, and say why in the `expect` message. - Errors: `thiserror` for a library's typed errors, `anyhow` for a binary's context chain. Follow whichever the project already has rather than adding the other. - Prefer borrowing to cloning, but don't contort a lifetime to avoid one `clone` in cold code. - A public API change (visibility, signature, trait bound) is a semver event in a library crate — say so in your findings rather than treating it as an internal edit. ## Inline unit tests are a shared-file split Rust puts u