Rust implementation tutorials

Create an editable tutorial and offline HTML from the user's plan. The user writes and commits the implementation unless they explicitly ask otherwise. Correctness and idiomatic Rust take precedence over shorter or easier-looking snippets.

Ground the tutorial

• Read the plan, repository instructions, current code, callers, Git status, and recent commits. Establish the starting revision, completed work, remaining behavior, and relevant tests.
• Preserve scope and commit boundaries. Do not restart completed steps or introduce unrelated refactors. Ask only about consequential choices the plan and repository do not resolve.
• Match the reader's Rust experience. Explain ownership, borrowing, lifetimes, trait bounds, patterns, conversions, error propagation, and iterators where the examples use them. Explain each concept when it matters, then refer back rather than repeating it.
• Inspect the installed dependency version before using an unfamiliar API. Follow repository Rust guidance and applicable Rust skills when available.

Make the Rust correct before teaching it

• Review the connected code, not only the proposed diff. Check invariants, compatibility, error paths, malformed input, and ownership across the whole operation. Follow the Rust review guidance.
• Prefer existing types, helpers, error conventions, and standard library facilities. Avoid abstractions introduced only to demonstrate a Rust feature. Use the least code that fully preserves the required behavior.
• Prefer borrowing over unnecessary cloning, but make an owned copy when mutation or lifetime requirements justify it and explain that cost. Use narrow visibility and only the trait bounds actually needed.
• Use checked conversions and explicit validation at input boundaries. A cast or invariant-based expect needs a reason established by the surrounding code. Propagate recoverable failures; do not turn malformed input into panics or silently discard meaningful data.
• Do not teach an unidiomatic shortcut because it is easier to explain, disable a useful lint to accommodate the example, or weaken a meaningful test just to obtain green checks. When a legitimate test assumption changes, replace it with a stronger behavior-level check and explain why.