The system is built and verified; what remains is the last act of the craft: delivering it. Delivering is not sending a ZIP — it is making it possible for someone else to install it without you, understand what it does and why, and see in ten minutes that it works. In this lesson you will write the definitive README, prepare a scripted demo, write the data report as a business deliverable (with the Sant Jordi order as the model), grade yourself with an honest rubric and run the retrospective that turns experience into learning. And since this is the last lesson of the course, we will end where one should end: looking back over the whole road from print("Hello, World") to here, and deciding — with judgment — what your next step is.

1. Documenting for others: the complete README
2. The demo: a 10-minute script
3. The final data report as a deliverable
4. Honest self-assessment: the rubric
5. Personal retrospective: five questions
6. Possible extensions, ranked by difficulty
7. The whole journey: from M1 to M12
8. Next steps with judgment
9. Papyrus was yours from the start

The README is the front door of the project: it is written for someone who wasn't there (including your six-months-from-now self, who won't be either). The acid test is literal: another person, with only the README, starts the project without asking you a single question. A real template, section by section:

Two details that separate a professional README from a decorative one: the copy-pastable usage example (the curl with its expected response: whoever pastes it and sees the 18.67 already trusts the project) and the known limitations section — documenting what is missing is not weakness, it is judgment; all real software has one, even when it isn't written down.

A demo without a script shows screens; a demo with a script tells a story. The story of Papyrus Online is "from the sale to the data", and this order tells it:

Three demo tips: rehearse it once in full (the unrehearsed demo fails — an empirical law), keep the commands pre-written in a file to paste them (typing live is throwing minutes away), and show a controlled failure on purpose: nothing builds more trust than a system cleanly rejecting an impossible sale. No audience? Record your screen while following the script. The discipline of narrating it out loud exposes every corner you don't fully understand — it is self-assessment disguised as theater.

The FR6 report is not a script that prints numbers: it is a business document Ana can read on a Monday morning. The deliverable (a Markdown or PDF with the PNG embedded) must contain exactly three things:

1. The period's numbers: total units and amount, top 3 titles, best day of the week, monthly evolution. With sales_2026.csv: 520 units over the half-year, Saturday as king (130 u), April running wild (168 u).
2. The chart: one, not six. The one that best tells the period's story (the monthly bar chart with April towering, the one from M11).
3. One actionable recommendation — the part almost everyone omits and the one that gives value to everything else. The model is the Sant Jordi order from 11-05:

"The regression (MAE ±1.1 units/day) projects 172 units for April 2027. Recommendation: an order of 190 units (projection + a ~10 % margin), split into two batches — 120 at the start of April, 70 in the week before Sant Jordi — to limit overstock risk. Watch Faust: 210 visits and an 11.9 % conversion rate suggest reviewing its price before the campaign."

Look at the anatomy: data → concrete recommendation (with a number) → risk management → a decision that stays in Ana's hands. Models recommend; people decide — M11's golden rule is also delivered in writing.

With no teacher, you set your own grade — all the more reason for the scale to be explicit. Assess each dimension and note the level in DECISIONS.md:

An honest reading: "Sufficient" across the board is already a huge achievement — a complete system built alone. "Good" is the reasonable professional standard. "Excellent" is aspirational: if you marked everything excellent, either you are very good or you weren't very honest — and the rubric only works once the second option is ruled out.

Experience doesn't teach; examined experience does. Close DECISIONS.md by answering in writing, calmly:

1. What cost me more than expected? (It points to your next area of study.)
2. What cost me less than expected? (It points to a strength you perhaps didn't know you had.)
3. Which design decision would I repeat, and which not? (Review your 12-02 decisions table with the truth of the code in front of you.)
4. What was the worst bug and what would have prevented it? (An earlier test, a clearer contract, a better-defined type…)
5. What would I do differently if I started tomorrow? (The answer is your personal list of lessons learned — worth more than any summary of ours.)

The ideas parked in 12-01 now have their place. Each with what you would have to learn — because "wanting to do it" without knowing what it involves is like estimating without data:

A rule for choosing: one extension, carried to completion, teaches more than three left halfway. You already know why: you learned it by finishing this project.

Look back for a moment, because the distance traveled is best seen from the end. In M1 you wrote print("Hello, World") and fighting the PATH was an adventure. In M2-M4 you learned to think in control flow and structures, and Papyrus was a list with four books. In M5 those books became objects with behavior; in M6 they survived a restart; in M7 the system learned to fail with grace and to leave a record in a log. M8 gave you the grown-up tools — type hints, decorators, generators, context managers — and M9 the one that changes everything: the ability to prove that your code works. In M10 Papyrus went out into the world over HTTP, twice and in two ways. In M11 its data spoke: Saturdays of 130 units, a Sant Jordi of 168, a Faust that gets looked at but not bought, a regression that projected 172 and a bookseller who ordered 190. And in M12 you learned nothing new — you did something harder: you assembled it all, alone, and it works. That sentence, twelve modules ago, was unthinkable. That sentence is the course.

"Now what?" has a better answer if you choose it out of real interest, not fashion. Three paths depending on what you enjoyed most:

All three share two tolls: git (no more excuses) and technical English (the real documentation lives there). And one cross-cutting piece of advice: from here on you learn by building — pick projects a bit bigger than your comfort zone, the way this one was.

A final confession: Papyrus was never the subject of the course. It was a vehicle — small enough to fit in a lesson, real enough to have stock to reconcile, members to validate and a Sant Jordi to plan for. The subject of the course was you, working on your own reality. So the last exercise is obvious: look at your job, your industry, your day-to-day. What is the "catalog" there? Case files, policies, bookings, patients, inventory? What is the "sale with rules": a calculation with discounts, a validation with exceptions, a process someone does by hand today? And what report would you hand to your "Ana"? Everything built here — layers, contracts, custom errors, tests, a CSV that turns into a decision — carries over as is. The first project you build on your domain will be harder than Papyrus, because nobody will hand you numbered requirements. It will also be the one that changes your professional profile.

• Shipping without testing the installation from scratch. Clone/copy your project to another folder, create a fresh venv and follow your README to the letter. It will fail on something (an unlisted dependency, a path) — better that you discover it than your reader.
• A demo without a rehearsal. The server that won't start, the JSON with one comma too many… The only vaccine is having run it once in full beforehand.
• A data report without a recommendation. Numbers without a proposed decision is work half done; the recommendation (with its risk managed) is the thing Ana cannot ask of a spreadsheet.
• Grading yourself up… or down. Inflating yourself blocks growth; beating yourself up blocks continuing. The rubric exists to pull you out of both: a level per dimension, with evidence.
• Never closing. There will always be one more refactor, one more extension. Projects get delivered: version 1.0, an honest README with limitations, and whatever comes next is version 2 — or the next project.

1. Final milestone — the delivery package. Complete the README with the template, verify the installation from scratch in a fresh venv, and produce the business report (numbers + PNG + recommendation) as REPORT.md. Verification: a person you trust (or you yourself, on another machine or in another folder, following only the README) starts the system and runs the tests without help.
2. Final milestone — the demo. Prepare the 10-minute script with your commands in a demo.md file, rehearse it once in full and, if you can, record it or show it to someone. Verification: you run it end to end without improvising or consulting anything outside the script.
3. Final milestone — closure and next step. Fill in the rubric and the five retrospective questions in DECISIONS.md, pick your path from the next-steps table and write the first concrete action with a date ("Saturday: basic git course"). Verification: the action is so concrete that on Saturday you will know exactly what to open.

1. There is no solution to copy: there is a success signal — the person following your README asks you zero questions. Every question they ask is a line your README is missing; add it and consider the exercise in progress until the questions reach zero.
2. Reference: the most common rehearsal failures are the server launched from the wrong folder (relative paths — 12-03 warned you) and "dirty" data from earlier trials; keep a clean demo data/ ready. If while narrating a step you can't explain why it works, write it down: it is the course's last lesson telling you where to review.
3. An example of a well-formed action: "Saturday 10:00: the official git tutorial through branching; create a repo for Papyrus Online and make the first commit with the delivered version." Badly formed: "learn git soon". The difference between the two is the same one you have been practicing for twelve modules: the verifiable versus the vague.

It's over — and this time there is no "in the next lesson". You began this course writing one line that greeted the world, and you finish it with a complete system that runs a business: a domain with rules and custom errors, persistence that loses no data, an interface that serves it, a test suite that proves it and a report that turns sales into decisions. More important than any single piece: you have shown that you can take requirements, design, build, verify and deliver with nobody holding your hand. That is not forgotten the way syntax is forgotten; it is a change of category. You take with you a method (contracts before code, validate-compute-mutate, every bug leaves its test, models recommend and people decide), a real project to show, and a map of next steps chosen with judgment. Ana's bookshop is in good hands — yours were the ones that built it. Now go and do to your own domain what you have done to Papyrus. It has been a privilege to walk with you since print("Hello, World"). The rest of the road is traveled the same way as this one: one line, one test and one project at a time. Safe travels, and good code.