---
id: standard.language.rust
version: 1.2.0
status: stable
---
# Rust Standard

## Apply by impact

Apply only rule groups activated by the current task or change-impact record. Do not invent
evidence for untouched surfaces; when a required gate asks about one, record why it is not
applicable.

## Rules
### Design and boundaries
- Model domain concepts with newtypes, enums, and modules. Keep adapters, FFI, persistence, and transport outside the domain core.
- Add traits at real substitution or testing seams; prefer concrete types until variation exists.
### Types and data
- Make invalid states unrepresentable where practical. Prefer exhaustive enums and typed IDs over strings, flags, or loosely related options.
- Keep generic bounds and lifetimes as simple as the ownership model permits.
### Errors and resources
- Use `Result` with contextual, actionable errors. Avoid `unwrap()` and `expect()` in library/runtime paths unless the invariant is proven and documented.
- Use RAII for resources; keep `unsafe` and FFI inside small safe abstractions with explicit invariants.
### Concurrency and state
- State `Send`/`Sync`, ordering, cancellation, backpressure, shutdown, and lock ownership expectations.
- Avoid holding locks across `.await`, unbounded channels/tasks, blocking executors, and detached work without lifecycle ownership.
### Testing
- Cover state transitions, error variants, serialization, feature flags, concurrency, and FFI boundaries. Use property or model tests for invariant-heavy code.
- Keep tests deterministic; isolate clocks, randomness, filesystem, and network dependencies.
### Performance
- Measure allocations, cloning, contention, and hot paths before optimizing. Avoid cloning as a default escape from ownership design.
### Security
- Minimise unsafe code, validate untrusted lengths and encodings, prevent integer overflow where attacker-controlled, and audit dependencies and feature flags.
### Public API documentation
- Add `//!` or `///` rustdoc to changed public crates, modules, structs, enums, traits, functions, methods, and caller-relevant error variants.
- Document panics, errors, side effects, ownership, concurrency, units, examples, and every public `unsafe` safety contract.
- Do not use rustdoc that merely repeats the item name or signature. Private items need comments when invariants or algorithms are non-obvious.
### Tooling and delivery
- Respect workspace MSRV, edition, features, lint policy, and crate boundaries. Keep public dependencies and default features intentional.
- Validate packages, examples, docs, and supported feature combinations before release.
## Review triggers
Review missing rustdoc, public unsafe APIs, panic across library boundaries, large trait surfaces,
nested bounds, unclear lifetimes, uncontrolled tasks, lock-order risk, FFI without a safe wrapper,
excess cloning, and feature combinations that are not compiled or tested.
## Required response
Update rustdoc and runnable examples, simplify types, isolate unsafe/FFI, make lifecycle and
errors explicit, add state-transition or property tests, and run formatter, Clippy, tests,
documentation tests, and relevant benchmarks.
## Exceptions
Complex generic, concurrent, or unsafe code may remain when it provides measured value and its
invariants are independently reviewable. Generated, vendored, compatibility-only, or
macro-generated public items may use narrowly configured exclusions.
## Evidence
Record `cargo fmt --check`, `cargo clippy -- -D warnings`, `cargo test`, feature-matrix, audit,
FFI, Miri/sanitizer, and benchmark results that apply. Record `cargo doc --no-deps`, rustdoc
warning status, and doctest results when applicable.