Rust rules file

---description: "Project rules for Rust, Cargo test, Cargo. Generated by RulePaste."alwaysApply: true--- # Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

---trigger: always_ondescription: "Project rules for Rust, Cargo test, Cargo. Generated by RulePaste."--- # Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Rust, Cargo test, Cargo. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Build: `cargo build`. Run: `cargo run`. Format: `cargo fmt`.- Tests: `cargo test`. Lint: `cargo clippy --all-targets -- -D warnings` if CI denies warnings, otherwise the clippy flags the repo already uses.- Add crates with a real version requirement. Commit `Cargo.lock` for applications. ## Rust - Match the edition and MSRV in `Cargo.toml`. Do not bump them as a side effect.- Format with rustfmt. If CI denies warnings, a new clippy warning is a failure.- Return `Result` with the crate's error type. `unwrap` and `expect` are for bugs, not for user input or IO. `expect` must name the invariant.- No `unsafe` unless safe Rust cannot do the job. An `unsafe` block starts with a comment that states why it is sound.- Prefer borrowing. Add dependencies with a real version, not `*`. Unit tests live in `#[cfg(test)]`. Integration tests live in `tests/`. ## Cargo tests - Unit tests sit in the same file under `#[cfg(test)]`. Integration tests sit in `tests/`.- A test name describes the behavior, for example `rejects_empty_name`.- `cargo test` passes for the crate you changed. Do not `#[ignore]` a test to go green. ## Cargo - Build with `cargo build`, test with `cargo test`, and format with `cargo fmt`.- Add crates with `cargo add` when the cargo-edit flow is available, or by editing `Cargo.toml` with a real version. Commit `Cargo.lock` for applications. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets.