Add Bevy-aware guidance and an ECS evaluation case

Proposal

Please add a short Bevy-specific reference to rust-best-practices and rust-review, together with a version-pinned ECS evaluation case.

This is an adaptation proposal based on reviewing the written source rules. I have not reproduced an AI-generated code regression, run an agent evaluation on Bevy, or performed a Bevy performance comparison.

Why this would help

The current writing guidance covers borrowing, visibility, imports, and lint policy, while the review guidance applies the same rules to existing code. A framework-specific note could help agents distinguish ordinary Rust APIs from Bevy's system interfaces and ECS conventions.

Suggested guidance

1. Preserve valid SystemParam signatures. Keep system parameters such as Res<T>, ResMut<T>, Query<...>, and Commands in the forms expected by Bevy. Do not mechanically replace a by-value Res<T> or Query<...> system parameter with a reference because the system only reads through it. This concerns the parameter wrapper, not component references inside a query. Ordinary helper functions can still follow normal borrowing advice. Check the project's Bevy version rather than applying a blanket rule to every parameter type. See Bevy's system parameters and ordering documentation.

2. Explain justified lint exceptions for ECS systems. Complex query types and multiple independent system parameters can reasonably warrant clippy::type_complexity and clippy::too_many_arguments exceptions. Bevy itself allows both in its workspace lint configuration. Prefer a documented, appropriately scoped exception when it preserves a clear ECS interface. SystemParam or query abstractions should improve clarity or reuse, not merely hide a warning or unnecessarily change component/resource boundaries.

3. Allow established framework preludes. Permit use bevy::prelude::* where consistent with project conventions; Bevy explicitly documents that import pattern. Distinguish consuming a framework prelude from introducing unnecessary application preludes. Clippy's wildcard_imports already exempts paths containing prelude by default, unless warn-on-all-wildcard-imports is enabled. No global disabling of wildcard-import checks is needed.

4. Clarify the existing passive-data exception. The writing skill already permits public fields for passive C-style data. Explain that simple Component and Resource data structures may fit this exception. Deriving those traits does not automatically justify exposing every field: types with invariants or public API compatibility requirements still need appropriate encapsulation.

5. Add ECS-specific correctness checks. Review meaningful system ordering, potentially conflicting mutable queries, and when deferred Commands become visible. For query conflicts, consider semantically correct disjoint filters or ParamSet, rather than merely making the code compile; see the official query documentation source. For deferred changes, account for Commands and the selected version's ApplyDeferred scheduling behavior, including automatically inserted synchronization points.

Proposed evaluation case

Add a small fixture pinned to a documented Bevy version, with:

• Valid by-value system parameters, a framework prelude, passive-data components/resources, and a justified complex query or multi-parameter system.
• A writing/refactoring check that preserves these valid patterns rather than introducing unnecessary changes.
• A review rubric that detects a real mutable-query conflict and a meaningful scheduling/deferred-visibility issue.
• Compilation and runtime tests for the relevant ECS behavior, not just lint cleanliness.

Keep the existing ownership, error-handling, safety, and project-policy checks. The goal is a narrow framework-aware extension, not a blanket exemption for Bevy code.