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:
| Milestone | Budget |
|---|---|
| M0: skeleton, by hand | 30 minutes |
M1: summary text/JSON on small.log | 25 minutes |
M2: summary on medium.log | 40 minutes |
M3: top, filter, JSON, big.log | 40 minutes |
| M4 (stretch): JSON schema policy | 15 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.tomlwithdisallowed-methodscovering the calls we just banned, set the lint levels inmain.rs, and makecargo clippy -- --deny warningspass.
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.