Generate an opinionated Cursor ruleset for a Rust or C++ systems repo

You are a senior systems engineer who configures AI assistants to write safe, idiomatic systems code. Generate a complete, opinionated Cursor rules file.

Repo context:
- Language: [Rust / C++ (standard: C++17/20/23)]
- Domain: [embedded / networking / database / CLI / library — and any constraints like 'no std' or 'no heap allocation in the hot path']
- Build system: [Cargo / CMake / Bazel]
- Async: [Tokio / async-std / none — sync only]
- Error handling convention (Rust): [thiserror for libs / anyhow for apps]
- Layout: [DESCRIBE — e.g. 'src/core/, src/ffi/, benches/, tests/']

Generate a single .cursorrules file specific to THIS repo. Cover at minimum:

1. Architecture map — module boundaries, what is public, the FFI or crate boundary if any.
2. Ownership and borrowing (Rust) — prefer borrowing over cloning, no unnecessary Arc or Clone, lifetimes annotated where non-obvious. For C++ — RAII, prefer smart pointers, no raw new or delete in app code.
3. Unsafe / raw-memory policy — where unsafe (Rust) or raw pointers (C++) is allowed, that every unsafe block carries a SAFETY comment justifying it, and the review bar.
4. Error handling — Result and Option (Rust), no unwrap in non-test code unless a comment justifies the invariant; for C++ the chosen error strategy and where exceptions are forbidden.
5. Concurrency — Send and Sync expectations, the async runtime, lock discipline, no blocking in async contexts.
6. Performance — no accidental allocations in hot paths, prefer iterators, profile before optimizing, name the bench harness.
7. Testing — unit tests beside code, property tests where relevant, integration tests in tests/, no test-only code in src/.
8. Build and CI rules — the lints (clippy pedantic / clang-tidy), formatting (rustfmt / clang-format), must-pass checks before a change is 'done'.

Critical format rules:
- Every rule MUST be followed by a one-line 'Why:' rationale.
- Be concrete to THIS language and domain. Ban wrong patterns by name (e.g. no Box::leak, no clone in a loop).
- Keep it under roughly 120 lines. No filler.

Output the full .cursorrules file in a single fenced code block, then a 5-bullet summary of the conventions it enforces.

Success signal: the output is good only if every rule has a rationale, the unsafe or raw-memory policy is explicit with a SAFETY-comment requirement, and the rules are specific to the chosen language's idioms.