v3: every doc opens with the role, then the mechanism, then the details — the docs were written bottom-up: what a thing does first ("Declares the three contexts WSProvider fills…"), details that only make sense once its purpose is known next, and the reason it exists last ("…so that a feed doesn't re-render"), so a reader had nothing to hang the first sentences on. The README's rule caused it, since a module doc "opened with what the module does"; it now opens with the module's role in the app, and the value-side phrasing of a type ("Returned to Y by X") comes once the role is said, with WSContext as the before and after. WSContext.ts is rewritten that way throughout, and so are the docs elsewhere that buried their purpose in a trailing "so that" (the migrations, og, image-proxy, public-address, useFading, useFeedCache, the drafts), opened on a generic verb that hid it ("Holds", "Declares", "Loads", "Defines", "Types": the contexts and providers, the shared types, the models, the hooks), or were label fragments ("The page of a dump…", "A row of tabs."). A function whose verb is its action ("Stores session"), a props or result type, and a protocol message ("Sent by X when Y") already say their role and are left as they are. Only comments changed, and the catalogs only move their references; deno fmt, deno lint and doc:lint are clean.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

shared/ws.ts

@@ -1,6 +1,7 @@
 /**
- * Defines the messages of the WebSocket between `WSProvider` in the client and
- * `routes/ws.ts` in the server, as JSON objects told apart by `type`.
+ * Live updates, votes, likes and the chat travel over one WebSocket between
+ * `WSProvider` in the client and `routes/ws.ts` in the server. This module
+ * types its messages, JSON objects told apart by `type`.
  *
  * The server's messages go out from `services/ws-service.ts`, and `WSProvider`
  * handles them. Their Dates arrive as strings, so the client reads them as