using-rust-engineering
Rust engineering checks
Work from compiler evidence, crate policy and supported targets. Answer familiar syntax questions directly; retrieve current documentation or a focused reference for uncertain behavior.
Work from the affected contract
- Read affected APIs/callers and Cargo/toolchain configuration. Identify edition, MSRV, enabled features, targets and intended error/resource behavior.
- Resolve ownership and trait errors by expressing the actual lifetime/API contract. Check object safety, Send/Sync and cancellation obligations before introducing clones, boxes or shared mutability.
- For unsafe/FFI, write the safety invariant and verify ownership, aliasing, alignment, initialization, provenance and unwind boundaries; use a safe API where possible.
- For performance, measure a representative optimized build with symbols and preserve semantics. For workspace or production PyO3 composition, select the dedicated pack only if that boundary is affected.
- Run affected compiler/lint/tests and relevant target/feature/Miri checks. State what was exercised, what was unavailable and any surviving soundness assumptions.
Scope and completion
Deliver a focused repair/design with diagnostics and behavior evidence. Avoid suppressing warnings broadly, upgrading toolchains by reflex, or requiring a full architecture/review ceremony for a compiler fix. Use structured errors, cancellation and unsafe obligations from the actual API, not generic preferences.
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.