Capstone: Write the Protocol
You have built the tower by watching it break, floor by floor. Now you are to prove that you own it, not by reading but by writing.
The task is to write the specification for Courtyard’s chat protocol: the document another engineer would need in order to build a client or a server that interoperates with yours. It is not code. It is the agreement, precise enough that two people who never speak could each implement one end and have the two ends work together. It should run to a few pages. The discipline is not length. The discipline is that every clause must name the rung of the tower that requires it. If you cannot say which failure a clause prevents, the clause does not belong, or else you have found a rung you did not understand.
Work down the tower, and for each rung decide, and say why. Framing comes first (Chapters 2 and 18). You are on a reliable stream, which has no edges, so how does the receiver find message boundaries? Is it a length prefix or a delimiter? What is the maximum message size, and what happens past it? Then message shape and evolution (Chapters 18 and 19). What are the message types, and what is in each body? Is it text or binary, and can you defend the choice? How does a field get added next year without breaking this year’s clients? State the compatibility rules you are committing to.
Liveness follows (Chapter 13). What is the heartbeat interval? How many misses before a peer is declared gone? What does the online indicator actually measure, and how stale can it be? Then connection and transport (Chapters 12, 16, and 17). Is it a reliable stream or datagrams, and why? Is it one long-lived connection or many? How does a client reconnect, and how does it avoid paying the slow-start cost of a new connection on every message?
Retry safety (Chapter 20) asks what happens when a client sends a message and the acknowledgement is lost. Where is the idempotency key, how is it generated, and how long must the server remember it? Security (Chapter 21) asks what is encrypted, what a client verifies before it trusts a server, and what metadata leaks anyway. And the upgrade (Chapter 18) asks how the connection begins, whether as HTTP and then upgraded or as something native, and what the handshake looks like.
The tower, as a checklist. Each rung is a row, and each row wants a clause and a justification. Once it is filled in, the gaps in your protocol are the rungs you left unaddressed.
A good specification has a property you can test for. For every clause, you can point at the chapter, and for every chapter, you can point at a clause. A clause with no chapter is something you added out of habit; cut it or justify it. A chapter with no clause is a decision you dodged. The stream really does have no edges whether or not your specification admits it, and a client that assumes one write is one read really will break. That two-way completeness is the whole of what it means to understand the tower rather than to have read about it. When you can produce it, Part I is yours.
Then Mira moves across the city, and the wire between your machines becomes a thing you do not own and cannot see. Every clause you have just written assumed a path that was there and would go on being there. In Part II you will find out which of your assumptions the path actually honours, and it is fewer than you would think.