Rust anti-slop

Make incorrect, vague, wasteful, difficult-to-review, and unjustified Rust code hard to introduce. Compiler and lint findings are evidence, not permission for mechanical rewrites. Preserve behavior, public contracts, supported targets, repository conventions, and unrelated work.

Route the task

Read each matching reference in full before acting. Do not load references for risks the task does not contain.

Templates under assets/ are reviewed starting points, not universal policy. The audit script may be executed without reading its source.

Shared invariants

1. Read repository instructions and inspect the task-local code path, manifests, toolchain/MSRV, relevant tests, git status, and the current diff before editing. Preserve unrelated work and never use destructive cleanup commands.
2. Honor the pinned toolchain, declared rust-version, feature model, supported targets, generated-code boundaries, and existing quality commands. Do not upgrade or broaden scope unless the task requires it.
3. Fix the underlying problem with the smallest coherent change. Do not launder compiler, borrow-checker, lint, or test failures with convenient clones, allocations, dynamic types, panics, broader visibility, dependencies, or suppressions.
4. Preserve error evidence and domain facts. Validate untyped data at boundaries and keep owned core logic typed.
5. Do not edit generated, vendored, copied, binding-generated, migration-generated, or macro-expanded output as owned source. Fix its source or exclude it narrowly.
6. No temporary slop in the completed change: unexplained TODO, FIXME, todo!, or unimplemented!; ignored errors; dead alternatives; debug output; speculative abstractions; or unjustified exceptions.
7. Never introduce repository-wide policy, optional tools, dependency updates, lockfile churn, or formatter-wide rewrites during an ordinary engineering task unless explicitly required. Do not run cargo fix, cargo clippy --fix, or broad automatic rewrites on a dirty repository without reviewing the exact scope first.

Work

1. Derive the behavioral contract from the request and repository evidence. Name the observable outcome, non-goals, and cheapest trustworthy proof before coding; distinguish facts, inferences, and pre-existing failures.
2. For a bug, reproduce the symptom before editing when safe and practical. If blocked, preserve the strongest existing evidence and report the verification gap rather than inventing a cause.
3. Select and read the matching references above. Map the blast radius and, for non-trivial multi-step work, define ordered units that each leave the repository coherent and end in a proof checkpoint.
4. Implement or recommend the smallest change that preserves the applicable ownership, error, lifecycle, concurrency, unsafe, feature, target, and public-API constraints.
5. Verify each unit before starting the next. If a checkpoint fails, stop and find the cause; do not build on an unverified state or add temporary compatibility code unless the final contract requires it.
6. Run focused checks first, then the repository's canonical formatter, compiler, Clippy, tests, rustdoc, and policy gates in proportion to the affected features and targets.
7. Prove the observable outcome through the narrowest real surface available. Compilation, Clippy, and self-authored tests support that proof but do not replace it when real behavior can be exercised.
8. Inspect the complete final diff, re-check affected consumers and invariants, and apply the acceptance gate in references/engineering-core.md to owned changed code.

Report

State the repository context and scope inspected, files changed, exact commands and results, fixed versus outstanding findings, every remaining exception or pre-existing failure, and anything not verified with the resulting risk. Never claim the repository is clean when a required gate was skipped or failed.