v3: the docs follow deno doc's grain — the index page was a hand-kept list of some 250 links into deno doc's output layout (./api/main.ts/index.html), policed by mod.test.ts; deno doc has no module index of its own beyond all_symbols.html, which lists every module by path with its summary. mod.ts is now a prose overview of the three parts and their layers, linking that list once, and mod.test.ts is gone. Re-exporting everything from mod.ts, as deno doc's tutorial does for a library, was tried and doesn't fit: export * drops the 18 routers (default exports) and makes 17 names ambiguous, and deno 2.9 renders export * as namespaces with the root's module doc and nested ones empty, losing every module doc. A router's page showed one line: its endpoint list sat on the default symbol, whose summary was cut at the colon introducing it; the list is now the module doc of all 18 routers, and the router's JSDoc says so. 22 summaries ended in a colon (the routers, BandcampPlayer, migration 0016, useDumpListSync, usePlaylistListSync) and read cut short wherever deno doc shows a first paragraph alone; they end in a full stop, doc-lint.ts now fails on a colon summary, and the README states the rule. No behaviour changes; 204 backend tests pass.

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

README.md

@@ -167,8 +167,11 @@ of an exported interface; a comment that describes a declaration is always `/**
 phrase. Parameters are named in the prose, in backticks. `{@link}` points at
 symbols the file already has in scope. A function that can throw to its caller
 says so with `@throws`: for an `APIException`, the statuses and when. A router's
-JSDoc lists its endpoints, one line each: method and path, who may call it, what
-it does; a page's names its route and who may see it.
+module doc lists its endpoints, one line each: method and path, who may call it,
+what it does; a page's JSDoc names its route and who may see it. The first
+paragraph of a doc is its summary, which the reference shows alone in lists, so
+it is a sentence that stands on its own: it never ends in a colon introducing
+what follows.
 
 In the frontend, every exported function states its return type, so the
 reference can show it: a component returns `React.JSX.Element` (or `| null`), a
@@ -180,12 +183,13 @@ rather than a default import of `react`, which `deno doc` can't follow.
 `deno task doc` builds the HTML reference into `docs/` from every module of
 `api/`, `shared/` and `src/` but the tests (and the generated `src/locales/`).
 Its index page is the module doc of `mod.ts` at the root, which introduces the
-repository's three parts and links every documented module (`mod.test.ts` checks
-it), and the `docs` workflow publishes it on every push to `main` that touches
-them. `deno task doc:lint` checks the rules the linter can see, through
-`doc-lint.ts`: `deno doc` doesn't document npm packages, so it takes a type
-imported from one (react-hook-form's `FieldValues`, say) for a private one, and
-those references alone are let through.
+repository's three parts and their layers in prose; `deno doc` builds the list
+of every module itself, grouped by path. The `docs` workflow publishes it on
+every push to `main` that touches them. `deno task doc:lint` checks the rules
+the linter can see, and that no summary ends in a colon, through `doc-lint.ts`.
+`deno doc` doesn't document npm packages, so it takes a type imported from one
+(react-hook-form's `FieldValues`, say) for a private one, and those references
+alone are let through.
 
 Each of the frontend's `components/`, `contexts/`, `hooks/` and `utils/` is
 split into the same domain folders — `auth`, `category`, `chat`, `comment`,