| name | systems-rust |
| description | Deliver Rust systems work across services, CLIs, WASM, and FFI while keeping ownership, async runtime, safety, and performance constraints explicit. |
Systems Rust
Use this pack for Rust systems work: performance-sensitive services, async runtimes, command-line tools, WebAssembly modules, native extensions, and cross-language boundaries where memory safety and throughput both matter.
Defer first-pass route choice and lane selection to ../../reference/routing-guidance.md.
This is the general Rust family pack for the repo. Use reference/axum-actix-wasm.md for Axum, Actix, and broad browser-facing WASM delivery. Use reference/wasm-browser-3d-performance.md only when browser-3D work already owned by frontend-web crosses a measured compute or transfer bottleneck and needs a narrow Rust/WASM escalation path.
Setup posture
- Prefer modernizing, refining, or extending an existing project in place.
- Treat scaffold,
create, init, or new flows as greenfield-only and explicit-request-only. Defer to reference/project-setup-policy.md.
Core focus
- Design ownership, borrowing, lifetimes, and crate boundaries so the data flow stays readable under change.
- Keep async runtime choices, task cancellation, channels, and backpressure explicit instead of hiding them behind helper layers.
- Treat WASM and FFI boundaries as contracts with typed inputs, serialization choices, and memory ownership rules.
- Optimize for high performance with zero-copy paths, predictable memory layout, profiling, and measured concurrency decisions.
- Keep error handling, tracing, testing, and release builds aligned with safe operational delivery.
Shared Rust systems standards
- Keep unsafe blocks, FFI shims, and boundary conversions narrow, visible, and easy to audit.
- Separate transport, runtime, and platform glue from reusable domain or library code.
- Use
wasm-bindgen, PyO3, cbindgen, uniffi, or similar boundary tooling deliberately, keeping ownership and type conversion explicit.
- Make target-specific code, feature flags, and cross-compilation assumptions visible in workspace or crate boundaries.
- Use benchmarks, tracing, and representative load tests before claiming a performance win.
Default workflow
- Inspect the workspace layout, crate graph, toolchain pinning, target platforms, and runtime model.
- Choose the Rust-specific overlay in
reference/axum-actix-wasm.md or, for measured browser-3D escalation work owned by frontend-web, reference/wasm-browser-3d-performance.md.
- Define ownership, async behavior, boundary contracts, and target assumptions before broad implementation.
- Implement crates, boundary code, tests, and benchmarks together so safety and performance stay aligned.
- Run
review skill after substantial Rust systems changes.
Collaboration in this repo
- Use research tools or the built-in Explore behavior before editing so new work matches local crate, module, and target-platform patterns.
- Use research tools, Context7, or equivalent knowledge retrieval when framework APIs, interop details, or platform constraints need a source-of-truth check.
- Use
review skill when Rust, WASM, or FFI changes materially affect safety, throughput, or integration behavior.
Overlays
reference/axum-actix-wasm.md for extractor and middleware choices in Rust HTTP services plus WASM boundary guidance for browser-facing performance work.reference/wasm-browser-3d-performance.md for escalation-only browser-3D WASM bottlenecks where measured geometry, simulation, parsing, or transfer pressure justifies the boundary.
Guardrails
- Do not hide ownership transfers or allocation-heavy boundary conversions inside convenience helpers.
- Do not mix runtimes, blocking calls, and async assumptions casually across the same request or worker path.
- Do not cross WASM or FFI boundaries with unstable layouts, implicit copies, or poorly defined error contracts.
