Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Milestones

The milestones are ordered so that stopping at any of them still gives a useful debrief. Each milestone ends with a review gate that feeds the next.

The project work is 2 hours 30 minutes, split around the afternoon break. As a rough budget:

MilestoneBudget
M0: skeleton, by hand30 minutes
M1: summary text/JSON on small.log25 minutes
M2: summary on medium.log40 minutes
M3: top, filter, JSON, big.log40 minutes
M4 (stretch): JSON schema policy15 minutes

The budget lands at M3, including requirement 1’s basic JSON output for every command. Only 15 of the 150 minutes are left for M4, and M2’s review gate is allowed to eat them, because that’s where the learning is. If you finish the two days without touching M4, you did the project as designed.

M0: Skeleton, before any generation

Write the skeleton by hand: the core types (which newtypes?), the parsing entry points, and the error types. Bodies are todo!(). If the design answers aren’t clear yet, run the design interview from this morning in a separate session first; the skeleton itself is still written by hand.

Run make check before the review; the gate isn’t passed until it’s green. Then swap skeletons with another pair and critique for two minutes each way, using the morning’s tables.

M1: summary works on small.log in text and JSON

Let the agent fill in bodies and wire up the CLI. Exercise both required formats; schema-versioning policy is deferred, not JSON implementation.

Review gate: run the thirty-second error review on the generated code and log the findings.

M2: summary handles medium.log

“Handles” means correct output, defined behavior for whatever the file contains, and a memory profile you can explain.

Review gate: grep for unwrap, clone, and <'a>. Each hit gets a row in the review log: either kept with a justification, or fixed with a prompt. For every policy row in your review log, point to the test that would fail if the policy broke. A row with no such test is a finding.

Guardrail step (part of M2)

Whatever your M2 review banned (an unwrap() on parse results, panicking on bad lines, a helper that reads the whole file into memory), ask the same agent for the matching check in the same session:

Write a clippy.toml with disallowed-methods covering the calls we just banned, set the lint levels in main.rs, and make cargo clippy -- --deny warnings pass.

Keep the configuration in the repository. The review made the decision once, and cargo clippy now applies it to every future change. See Build Your Own Guardrails.

M3: top and filter in both formats; big.log under 60 seconds

Build in release mode before timing, so compilation is excluded. Use the well-formed 90,000,000-line big.log, then record elapsed time and peak memory on the classroom machine in the review log.

Review gate: does the requirement 4 architecture exist? Could a teammate add a new subcommand against your core API without touching the parser? Before closing M3, run summary, top, and filter with both --format text and --format json; basic JSON support is required, not stretch work.

M4 (stretch): JSON schema policy

M1 and M3 already implemented the required JSON outputs. Requirement 1 also says that JSON must be “stable enough to consume from a script”. Decide what compatibility means beyond the working schema, write it down as a spec amendment, have the agent harden it, and test it.