Rings, not modules

What are we doing here.

§A different question from "which file does what"

Most codebases answer "how is this organised" with a list of folders and a sentence per folder. That is useful, and this part gives you that list too (6.3). But the codebase behind this book answers a stronger question first, and the stronger question is the more useful one to carry around: who is allowed to talk to whom.

Picture the machine as a set of rings around a centre, like a target or a tree's growth rings. The centre is the raw machinery — the one place where the log actually lives and the rules that move it forward. Around that sits a ring that turns raw machinery into something a request can be made of. Around that, a ring that remembers a session between requests. Around that, a ring of named actions — "open a Cell", "attest", "ask a question" — that a caller can actually invoke. Around that, the wire — an HTTP surface anyone can call. And around everything, what a person actually looks at on screen.

§The one rule that matters more than any folder name

A ring may only ever reach its own next-inner neighbour. Not "should, as a matter of style" — the codebase checks this mechanically, by scanning every file's imports (tests/ring-discipline.test.ts). The screen never imports the raw log machinery directly. The named actions never import the wire. A ring skipping past its neighbour to grab something two rings in is not a shortcut here; it is a defect the test suite catches before anything ships.

§Why this is worth a whole part of the book

Because it is the answer to a question every reader of this book will eventually ask: "if I change how a finding is shown on screen, could that possibly change what the finding actually says?" With rings enforced this way, the answer is a flat no — the ring that shows things can only ever read what an inner ring already decided; it cannot write anything back, and it cannot reach past the reading it was given to touch the log underneath. 6.2 argues this is not incidental tidiness but a requirement of doing analytical work honestly at all.

§The picture to hold onto

   [screen]  →  [wire]  →  [named actions]  →  [session memory]  →  [raw machinery]
      ↑                                                                    │
      └──────────────── everything the screen sees is read back out ──────┘
                          through the SAME rings, never around them

A gesture goes in from the outside, crosses every ring inward, and its consequences come back out through the same rings, never a shortcut. 6.4 walks exactly one gesture along this whole path with real file names.