Rust Pro

Table of Contents

• When to use
• Required inputs
• Deliverables
• Ownership Rules
• Error Handling
• Examples
• Failure mode
• Gotchas

When to use

• Use for Rust implementation or review work.
• Use when correctness, safety, and performance all matter.

Required inputs

• Target crate/module.
• Borrowing/ownership constraints.
• Error semantics and runtime expectations.

Deliverables

• Safe and idiomatic Rust updates.
• Explicit error propagation.
• Notes on any performance-sensitive decisions.

Ownership Rules

• Prefer borrowing over cloning in hot paths.
• Use iterators before indexing loops when possible.
• Keep lifetimes implicit unless explicit annotations improve clarity.

Error Handling

• Prefer Result<T, E> for recoverable paths.
• Use domain-specific error enums over stringly-typed errors.
• Attach context when propagating errors.

Examples

pub fn parse_port(value: &str) -> Result<u16, String> {
    value.parse::<u16>().map_err(|_| format!("invalid port: {value}"))
}

Failure mode

• If ownership requirements conflict, favor correctness and simplify data flow.

Gotchas

• Overusing clone() can hide unnecessary allocations.

See Also

Topic map: [[agent-ops]]

Philosophy

• Optimize for clear, verifiable outcomes with the minimum necessary changes.
• Keep guidance deterministic so repeated runs produce consistent decisions.

Procedure

1. Confirm scope, constraints, and required inputs before edits.
2. Apply focused changes tied directly to the requested outcome.
3. Re-run the highest-signal validations and capture concrete evidence.

Validation

• Run the relevant local checks for touched files and workflow contracts.
• Fail fast: stop at the first blocking validation failure and report exact evidence.
• Re-run checks after fixes and record residual risk if any remains.

Constraints

• Redact secrets, tokens, credentials, and sensitive data by default.
• Do not expand scope beyond the request unless explicitly asked.
• Prefer safe, reversible edits over broad refactors.

Anti-patterns

• Skipping validation after making changes.
• Applying broad refactors to solve narrow issues.
• Assuming behavior without evidence from current checks.

References and assets

• Open deep guidance: Infrastructure/references/deep-guidance.md
• Read when: the task needs advanced edge cases, migration-safe patterns, or runtime-specific nuance beyond the core checklist.