# Repository agent rules

- When creating a new Rust file, format ONLY that new file with the Cargo formatter (`rustfmt --edition 2024 --config skip_children=true path/to/new_file.rs`). Use the file’s actual Rust edition. Never run workspace-wide or package-wide `cargo fmt`, and never format existing files unless explicitly requested.
- Do not run other automatic code-formatting commands unless explicitly requested.
- Keep SQL easy to scan and preserve existing readable layouts. Short queries and simple subqueries may stay on one line; for example, keep each simple `EXISTS (SELECT 1 FROM ... WHERE ...)` condition together, with successive `OR EXISTS` conditions on separate lines. Use multiline layout and indentation when query complexity or line length warrants it, especially for long SELECT lists, multiple JOINs, or nested logic. Do not mechanically put every clause on its own line or expand compact SQL just to satisfy a formatting rule. Review SQL inside Rust strings manually; do not reformat unrelated queries.
- Preserve existing formatting. Make only the smallest hand-edited changes required for the task.
- Do not run builds, checks, linters, or pre-existing tests. Only run tests that an agent wrote or modified as part of the current task; if the agent did not write or modify any tests, run no tests.
- Check if what you are doing is running. Server can be running, tauri app might be running. No need to turn on redundant systems.

## Typed domain values

- Use enums/domain types for states, kinds, policies, and operations. Parse strings and protobuf integers at boundaries, reject invalid values, and keep internal logic typed.
- Use typed protobuf contracts too; update affected clients, bindings, and descriptors together. Breaking changes are acceptable; add compatibility only when explicitly requested.
- Keep strings for free text, names, storage, language syntax, and display. Diagnostic labels must never control business logic.

## Disk constraints

This workspace is heavily disk constrained. Do not run any command that may create a new or substantially different artifact graph unless the user explicitly authorizes the disk cost.

- Reuse the repository's existing build caches only. A build, check, or test is permitted only when its exact package, feature set, profile, and target directory are already known to be cached. If cache reuse is uncertain, do not run it; report that verification was not run.
- Do not create persistent alternate target directories or copy build artifacts inside the workspace. Temporary artifacts, including an isolated `CARGO_TARGET_DIR`, may be placed under `/tmp` only when they are necessary and are fully removed immediately after the command finishes.
- Every `/tmp` workspace must be created as a unique, narrowly scoped directory (prefer `mktemp -d`), tracked explicitly, and removed on success, failure, or interruption. Use a shell cleanup trap when one command owns the directory. Before deletion, verify the resolved path is the exact temporary directory under `/tmp`; never delete `/tmp` itself or use a broad glob.
- Do not leave a `/tmp` build or other artifact-producing command running when its cleanup depends on the agent returning later. If a command may outlive the tool call, use the persistent, already-cached workspace target instead or do not run it.
- Do not change Cargo features, profiles, targets, toolchains, or package selections merely to work around a lock or compile failure; doing so creates another artifact graph.
- Do not run dependency-fetching or installation commands such as `cargo fetch`, `cargo install`, `nix build`, `nix shell`, `nix develop`, `npm install`, `yarn install`, or equivalents unless the user explicitly requests them and confirms the required artifacts are already cached or accepts the disk usage.
- Do not invoke Nix commands that may realize new store paths. Read-only evaluation is allowed only when it is known not to fetch or realize anything; otherwise inspect existing files and environment state instead.
- Prefer artifact-free validation: inspect diffs, use `rg`, read source files, and run `git diff --check`. Small interpreted tests are acceptable only when they do not install dependencies, create caches, or emit build artifacts.
- Never run cleanup or garbage-collection commands (`cargo clean`, deleting `target`, Nix garbage collection, or similar) without an explicit user request. Disk pressure does not authorize deleting potentially reusable user data.
- Existing background build/watch processes belong to the user. Do not start a competing build to bypass their lock, and do not redirect compilation elsewhere.

## Long-running commands

- Never repeatedly poll a running command.
- Wait at most 10 seconds initially. If the command is still running, leave it running, report the command and session ID, and end the turn immediately.
- Do not poll the command again unless the user explicitly asks for its status.
- Do not start optional slow checks.
- Before starting a required command that cannot safely be left running, ask the user for permission.