v3: comments say what the code can't — the documentation pass wanted JSDoc on every export and every field of an exported interface, which filled the code with restatements ("The dump.", "Whether it is loading.", "The props of X.", "Renders the X.") and module docs that told a reader nothing ("The hot and new feeds, and the props every main feed of the index takes."); some were wrong as well as vague. Every comment in api/, shared/ and src/ is rewritten under one rule, now stated in the README's "Comments" section: every module and export still has a JSDoc, and it gives context (who uses it and where), usage (what a caller must know: a precondition, what it leaves to the caller, a side effect) or its place in the chain (where its input comes from, where its output goes); a field, parameter, private function or local gets one only when it adds to its parent's, and context about a whole type goes on the type; a type's doc is phrased from the value's side ("Returned to Y by X when Z", "Passed to Y by X"); full sentences, as short as they can be, no label-colon-list; // goes wherever the code isn't obvious and says why, and the section banners and narration go. Every claim was checked against the code, which turned up some forty comments that were wrong: DumpCard's claimed it was only used by the hot and new feeds, the WebSocket welcome claimed to be a socket's first message (presence comes first), UpdateUserRequest said null removes a description (it keeps it), deletedDumpIds leaves out that it also holds dumps made private, THEME_COLOR claimed to mirror index.html's, and the like. The routers' JSDoc now says where they are mounted and what becomes of a thrown APIException. doc-lint.ts lets a field without a doc through; a module or export without one still fails. No code changes; 204 backend and 628 frontend tests pass, and doc:lint, deno check, deno lint and tsc are clean.

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

api/db/migrations/0012_fix_favicon_reclassification.ts

@@ -1,30 +1,19 @@
 /**
- * Repairs 0011, which was too eager about what counts as a site icon.
+ * Repairs the rows 0011 got wrong. 0011 took any path containing "favicon",
+ * or ending in `.svg`, for an icon, so artwork such as
+ * `/wp-content/uploads/2022/04/mir-logo-favicon.png` lost its `thumbnailUrl`,
+ * and its dump showed as a pull-quote instead of an image in the journal
+ * mosaic.
  *
- * 0011 tested for "favicon" anywhere in the path, so a legitimate `og:image`
- * like mirtitles.org's `/wp-content/uploads/2022/04/mir-logo-favicon.png` was
- * moved into `faviconUrl` and its `thumbnailUrl` cleared — which also demoted
- * the dump from an image card to a pull-quote in the journal mosaic. A blanket
- * `.svg` match had the same effect on real artwork.
- *
- * `isIconUrl` here looks at the *filename* rather than the whole path: an icon
- * is named `favicon…`, `apple-touch-icon…` or `icon…`, lives in an `icons/`
- * directory, or ends in `.ico`. That both spares `mir-logo-favicon.png` and
- * catches `icon_SEARCH.png`, which 0011 missed.
- *
- * Applied in both directions, and deliberately narrow when reversing: a value
- * is only promoted back to `thumbnailUrl` if it matches 0011's rule but not
- * this one, so rows written by a normal fetch aren't disturbed.
+ * This rule judges the file name and its folder instead. It spares
+ * `mir-logo-favicon.png` and catches `icon_SEARCH.png`, which 0011 missed.
  *
  * @module
  */
 
 import type { DatabaseSync } from "node:sqlite";
 
-/**
- * Applies 0011's rule, kept verbatim so its false positives can be
- * identified.
- */
+/** 0011's rule, copied as it shipped, to tell which rows it moved. */
 function wasIconUrl0011(raw: string): boolean {
   let pathname: string;
   try {
@@ -37,8 +26,9 @@ function wasIconUrl0011(raw: string): boolean {
 }
 
 /**
- * Checks whether a URL names a site icon, judged on its filename and
- * directory.
+ * Checks whether a URL is a site icon. It is one when the file ends in `.ico`,
+ * sits in a `favicon(s)` or `icon(s)` folder, or is named `favicon`,
+ * `apple-touch-icon` or `icon`, alone or followed by a digit, `-`, `_` or `.`.
  */
 function isIconUrl(raw: string): boolean {
   let pathname: string;
@@ -55,7 +45,12 @@ function isIconUrl(raw: string): boolean {
   return /^(favicon|apple-touch-icon|icon)(?=$|[-_.\d])/i.test(basename);
 }
 
-/** Applies this migration to `db`. */
+/**
+ * Run once by `runMigrations`. It moves a `faviconUrl` back to `thumbnailUrl`
+ * only when 0011's rule takes it for an icon and this one doesn't. That also
+ * catches the ones a later fetch stored that this rule doesn't recognise, such
+ * as a `logo.svg`. It then moves the icons 0011 missed.
+ */
 export function up(db: DatabaseSync): void {
   const rows = db.prepare(
     `SELECT id, rich_content FROM dumps
@@ -73,10 +68,9 @@ export function up(db: DatabaseSync): void {
     try {
       rich = JSON.parse(row.rich_content);
     } catch {
-      continue; // malformed payload — leave it untouched
+      continue;
     }
 
-    // Artwork 0011 mistook for an icon: put it back.
     if (
       rich.faviconUrl && !rich.thumbnailUrl &&
       wasIconUrl0011(rich.faviconUrl) && !isIconUrl(rich.faviconUrl)
@@ -90,7 +84,6 @@ export function up(db: DatabaseSync): void {
       continue;
     }
 
-    // An icon 0011's rule didn't recognize: move it now.
     if (
       rich.thumbnailUrl && !rich.faviconUrl && isIconUrl(rich.thumbnailUrl)
     ) {