Grow from intermediate to advanced by building a product

After stages 01–10, develop one work-log product called Trail. Use it to discover an actual inconvenience, learn the Rust concepts required to address that inconvenience, and verify the effect of your change.

The goal is to move from writing a feature to explaining how a design behaves under failure, load, and change. Advanced practice is not measured by the amount of unsafe code or the number of frameworks.

The implemented starting point

Trail v0 is implemented and runnable. It records a task name and duration, lists records after restart, and computes a total.

You implement stages 11–30 yourself. The times below are planning estimates, not certifications or deadlines. Split a stage into 60–90-minute sessions and use observations from actual use to select the next improvement.

Five product phases

Phase	What to build	Rust concepts	Estimate	Observable milestone
11–14: usable CLI	Types, dates, tags, summaries, and arguments	Invariants, ownership, errors, modules	8–12 hours	Use it for a week and make one improvement
15–18: storage and data	JSON, SQLite, edits, and import	Serde, traits, boundaries, transactions, property tests	12–18 hours	Invalid input cannot destroy existing records
19–22: local web	API, input form, and summary screen	Async, Tokio, Axum, shared state, observation	16–24 hours	Save from the browser and view the result after restart
23–26: long work and recovery	Jobs, progress, retry, and restart	Channels, Send/Sync, state machines, cancellation, idempotency	20–30 hours	Reproduce interruption, duplicate requests, and overload, then demonstrate recovery
27–30: maintenance and distribution	A stable library, measurements, and release	Lifetimes, Cow, trait design, profiling, interface design	20–30 hours	Reproduce the release and operating procedure in another environment

The total estimate is 76–114 hours. Prioritize understanding and actual use. If you already meet a stage’s conditions, demonstrate them and shorten that stage.

A working procedure for each stage

1. Use it. Try the current feature and state the user’s inconvenience in one sentence.
2. Specify the contract. Use three concrete examples to define input, output, failure, and durable state.
3. Complete one vertical path. Connect input through persistence to visible result for one feature. Do not build many layers before the path works.
4. Verify. Try success, boundaries, and failure. If you use a filtered test command, confirm that it executed the intended tests rather than passing with zero matches.
5. Observe. Use a small fixture resembling real data to inspect logs, variables, elapsed time, and remaining state.
6. Explain the design. Record the chosen method, alternative, deliberately unsupported guarantees, and measurements in four to six lines.
7. Revise. Update usage instructions and observations, and commit one coherent change.

“Import a large CSV” is too broad for an initial session. First implement “validate three rows and save only when every row is valid.” The larger work can grow from that observable path.

Connect exercises to understanding

Exercise	Stage	Practice
ex07	13	Deterministic aggregation order; borrowing input and producing owned results
ex08	23	Representing allowed job-state transitions
ex09	24	Bounded backoff and integer boundaries
ex10	18 and 24	Stable-order deduplication and reference lifetimes

cd labs/rust
cargo test -p exercises ex07 -- --ignored
cargo run -p trail --example bounded_queue

These exercises are small learning functions. After passing them, apply the same reasoning in the product. In-memory deduplication alone cannot guarantee idempotency across a restart.

Questions to ask before writing code

The mental models support design decisions rather than act as a vocabulary dictionary. Link each task to the model it needs.

• Ownership: who owns this value, and for how long?
• Boundaries and invariants: at which point may an external value be trusted?
• Async and queues: what are we waiting for, and how much new work can we accept?
• Persistence and response: what has committed, and what has the user observed?
• Performance: which quantity should decrease, under which conditions?

Use the admission, processing, and queue simulation at /en/rust/visuals/product.html. Try a retry after a lost response, then reproduce the same state in an implementation test. The visualization predicts a behavior; execution checks it.

Ask for support with a concrete observation

For example: “Stage 16: saving works, but I am worried about a failure halfway through an edit. Explain the idea with a diagram first, then let me write a test.” State the stage, observation, and uncertainty together.

Follow small example → your implementation → execution → counterexample → explanation. Copying a complete solution is insufficient. Record the change you made, the evidence you observed, and the guarantees you have not established in the learning log.

What advanced completion looks like

At the final stage, another person should be able to verify that:

• You can demonstrate normal use and explain the state after invalid input.
• You can draw ownership and commit boundaries across API, database, and worker.
• Relevant property, concurrency, interruption, and retry tests exist, and you can explain their limits.
• You measured a slow path and compared the original and changed implementation under the same conditions.
• You kept changes small and reproduced migration, recovery, and release procedures in another environment.

Finally, apply the design reasoning to a different small product. Good decisions under different data and load are stronger evidence than simply completing this curriculum. In Kumyu product code, obsolete compatibility behavior and silent fallback are excluded; study alternatives to understand their tradeoffs, then implement the one current contract you need.

Use the AI migration story as a review protocol, not a scope promise

The Trail v0 link describes an implemented starting point; stages 11–30 are planned learner work. Keep that distinction in every issue, commit, and demo. The 2024 goals and the 2025 Rust 2024 release show a language evolution path, but they do not certify a product architecture. A product stage still needs its own input contract, durable-state rule, and recovery evidence.

A current AI case supplies a useful discipline. Google’s 2026-10-01 Argon announcement describes C/C++ migrations that use profile-guided experiments, compiler-output study, auditing, emulation testing, and review. It is Google’s claim about its own work, not a Trail benchmark. Translate its sequence to stage 18 or 24: first capture an invariant and a failing fixture; make one small change; run the focused persistence or recovery test; inspect the diff; then run the full relevant suite. For a candidate performance change, record a baseline, fixture size, hardware/toolchain, repetitions, output equality check, and rollback plan.

Build one AI-assisted feature under a strict review envelope: ask a model for three test cases, choose one only after you can explain it, implement the smallest vertical path, and add an explicit rejection test. Then kill the process during a save or queue transition and document the observed state after restart. Community threads about AI-generated Rust work express concerns about maintainability and low-effort publishing; they are experience reports, not evidence that AI code is always unsafe. The appropriate conclusion is traceable ownership of every change.