A file-watching version of Chapter 5's duplicate finder. The current Dup_Finder scans once and returns. Watching a directory continuously and re-scanning only what changed is a genuinely different design problem — incremental state instead of a clean one-shot pass. It deserved its own chapter, more than a paragraph tacked onto Part III.
A second Java toolkit, to test whether Chapter 8's lesson generalizes. This book crosses into javax.swing exactly once. Whether the same isolation pattern — capture events in plain Nex state, render separately — holds for a different host library (a database driver, a different UI toolkit, an existing Java service client) is an open question this book doesn't answer, on purpose. One crossing, examined carefully, teaches the discipline better than several crossings examined thinly.
Authentication and authorization on Chapter 7's HTTP API. calc_service trusts every request. A real API boundary — API keys, rate limiting, a contract about who is allowed to call what — is a natural extension of the same chapter's "parse, don't validate" reasoning, applied to a caller's identity instead of a request body. It was left out to keep that chapter's focus on the translation layer between a language-level contract and an HTTP status code.
A persistent version of Chapter 6's chat server. Messages vanish the moment the hub task exits. Logging them — reusing Chapter 2's schema-versioning discipline for a message history instead of a task list — is a natural bridge between two parts of this book that never talk to each other otherwise.
Backpressure, for real, somewhere. Chapter 5's cancellation illustration is deliberately separate from its actual scan. Nothing in this book has a channel or a task queue that can genuinely fill up and has to decide what to do about it. A producer that outpaces its consumer — a log ingester, a bounded work queue — would put a real bounded Channel under real pressure. None of these nine projects ever do that.
None of these projects were required for the book's core idea — that contracts, stated before code, hold across a CLI, a library, concurrency, a network, and a GUI. They're included as optional extensions, not obligations. The same five-part structure used in every chapter (Problem, Design as Contract, Build, Test, Takeaways) works just as well on a project the book hasn't written up yet.