Lesson 5: Apply this to your own project

Lesson 5: Apply this to your own project

Objective

You select one real script you own, write its task contract (from Lesson 2), and apply the smallest useful slice of this course to it — with tests, a verify command, and a written record of what the tests do not prove.

Why this lesson exists

Course projects are forgiving: the data is small, the tests exist, the contract is written for you. Your project is where the habits either transfer or evaporate. The transfer works when you shrink the scope: one script, one contract, one failing test made to pass — not a rewrite.

The lesson

1. Pick the script. One you run repeatedly and have been mildly afraid of. Not the biggest one — the most annoying one.
2. Write its contract (Lesson 2 exercise): three behavior statements, one boundary clause, one acceptance command.
3. Add one failing test for the scariest contract line. Copy the shape from tests/test_report_tool.py — tempfile for outputs, inline data, one assertion per behavior.
4. Have the agent make it pass under Lesson 3’s rules: smallest change, show the diff, no drive-by refactors.
5. Write the verification record (Lesson 4): verified / not verified / known limits.

Which pattern to port depends on your script’s actual failure mode:

If your script…	Port this course pattern
crashes on one bad row	error isolation with {"index", "reason"} collection
prints 0.30000000000000004	two-decimal rounding at aggregation boundaries
leaves half-written output when interrupted	atomic write via temp file + os.replace
mixes two input formats	one loader, explicit unsupported-type rejection
has no way to say “done”	the verify command: failing starter, passing target

What verification does not prove

Be equally clear about the limits, because overselling tests is how projects get hurt:

• Passing tests prove the pinned behaviors on the tested inputs — not correctness on tomorrow’s data, not absence of bugs elsewhere.
• A green suite says nothing about performance on production-sized files, or about the upstream system changing its schema next month.
• The repo’s tests are not your outcome. Your outcome is a user-visible behavior (a correct report delivered, a crash eliminated), with tests as evidence. For the full framing, read the companion guide “Use Python Well with AI Coding” and the product-quality guide (flypython.com or the repository guides/ directory).

Exercise

Ship the slice. Run your new acceptance command from a clean checkout of your project (or a colleague’s machine) and confirm it reproduces the same result. If it does not, your command depends on your machine — fix the command, not the excuse.

Checkpoint

Your project now has: a written contract, one test that used to fail and now passes, a single command that demonstrates both, and a three-line verification record. That is the whole course, compressed into your codebase.

Expected evidence

The contract, the test transcript, and the verification record. If you found the workflow useful, the course’s landing page lists where to go next — and the course-feedback issue form is where teaching drift gets fixed.