Chapter 23: Capstone - Prove and Hand Over Your Platform
Learning Objectives
By the end of this chapter, you will be able to:
- Take one change through the whole path on your own - pull request, staging, production - and prove it on the users’ path, not by a status
- Notice a breaking change you did not make, prove its cause from the symptoms, and fix it through Git
- Judge an AI agent’s proposal against the platform’s guardrails, and accept or reject it with a reason you can show
- Hand the platform over: what it does, what you proved and how, what it does not protect against, and what has to change before real users
- Ask the same questions of a system you did not build: what can break, what to check first, the smallest change to make first
Recall Check
Before continuing, quickly recall:
- How does a feature flag separate writing from reading, and why does changing one roll the pods? (Chapter 18)
- Who may add a PolicyException, and what must it carry to pass review? (Chapter 16)
- In a postmortem, what separates an observation from an assumption? (Chapter 15)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
Every chapter so far taught one part of the platform, with commands and their expected output. Real work comes with neither: a goal, some constraints, someone else’s change landing while you work, a confident suggestion - and, at the end, a person who takes over from you. The capstone is that week, on your own kind cluster.
Three things are different from every lab before it:
- No commands for the work. The assignment says what must be true and how it is checked; how you get there is yours. Every command you need has appeared in an earlier chapter, and its runbooks are there to use.
- Something breaks that you did not change.
make capstone-faultplays a colleague: it merges one plausible pull request into your repository, picked at random from a few known faults. It passes every check, like the changes that really cause incidents. Noticing it, proving it and fixing it through Git is part of the work. - Evidence decides. Every acceptance criterion has a check, and
make capstone-checkruns them against Git and the cluster. What no script can check - the users’ path, your reasoning, the decision on the AI’s proposal - goes into a handover, each claim with its evidence.
Each criterion ends at one of three levels:
- Proven - the check passes and the handover holds the evidence, found on your own;
- Proven with a hint - the same, after opening one of the lab’s hints; the handover says which. Using one is not failing: it is honest evidence of where you needed it;
- Not proven yet - the check fails, or the evidence is missing. It names the chapter to go back to.
This capstone is one way to finish a course like this, not the only one: a Game Day with several failures at once tests incident coordination harder; a production readiness review asks the same questions of a new service before it launches; a design review asks them of the platform before it is built. This one tests the whole path for one change, with one surprise - small enough to finish in an afternoon.
It runs on kind only. The Hetzner cluster appears in the handover, as part of what changes before real users.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
The Capstone in One Picture
