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>

README.md

@@ -188,9 +188,20 @@ one of:
    Add an example only when the call isn't obvious.
 3. **Place in the chain**: where its input comes from and where its output goes.
 
-A type's doc is phrased from the value's side, naming the producer and the
-consumer: "Returned to Y by X when Z", "Passed to Y by X". It is never "What X
-returns to Y" or "What X passes to Y".
+**A doc opens with the role, then the mechanism, then the details.** Its first
+sentence says what part of the app the thing serves or what problem it solves,
+so a reader who has never seen it knows why it exists. How it does that (what
+feeds it, what reads it, how it's split) comes next, and the details last. Each
+sentence makes sense given only the ones before it. Not "Declares the three
+contexts `WSProvider` fills from the WebSocket. They are split so that a feed
+doesn't re-render with every chat message", which leaves the reason for last,
+but "Live updates from the server reach the pages through three contexts, split
+so that a feed doesn't re-render with every chat message. `WSProvider` fills
+them from its WebSocket."
+
+Once the role is said, a type's doc is phrased from the value's side, naming the
+producer and the consumer: "Returned to Y by X when Z", "Passed to Y by X". It
+is never "What X returns to Y" or "What X passes to Y".
 
 Don't pack a doc into a label followed by a colon and a list ("X: one thing,
 plus some other thing"). Write sentences with a subject and a verb.
@@ -209,13 +220,13 @@ and locals. None of these count as a doc:
 
 When a comment is there, it is as short as it can be, often one sentence, and it
 is written in full sentences. Labels and fragments ("Upvotes on dumps.") don't
-count. A module doc is a few lines at most. It opens with what the module does,
-then says who calls it and what it hands back, and it doesn't repeat what its
-exports' docs say. `@throws` stays on whatever throws to its caller, with the
-statuses of an `APIException` and when each happens. A router's module doc lists
-its endpoints (method, path, who may call it), since the code states them
-nowhere in one place. A summary never ends in a colon: the reference shows it
-alone.
+count. A module doc is a few lines at most. It opens with the module's role in
+the app, then says how it plays it, who calls it and what it hands back, and it
+doesn't repeat what its exports' docs say. `@throws` stays on whatever throws to
+its caller, with the statuses of an `APIException` and when each happens. A
+router's module doc lists its endpoints (method, path, who may call it), since
+the code states them nowhere in one place. A summary never ends in a colon: the
+reference shows it alone.
 
 **`//` comments** go wherever the code isn't obvious. They explain why, not
 what: a workaround, an ordering constraint, a surprising limitation, a security