@kurtbruns/kestrel 1.21.0 → 1.22.0

package/dist/public/dashboard/index.html

@@ -5,7 +5,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Kestrel</title>
 <link rel="icon" href="/favicon.svg">
-<link rel="stylesheet" href="./styles.css?v=aacdaf66">
+<link rel="stylesheet" href="./styles.css?v=102ce128">
 <script>
 // Sidebar mode guard — set the width-based data-nav on <html> before first paint so the
 // sidebar renders in its final width with no flash. The collapse toggle's override is
@@ -116,6 +116,6 @@
 </section>
 <div id="toasts" role="status" aria-live="polite"></div>
 
-<script src="./app.js?v=e3dbd207"></script>
+<script src="./app.js?v=867db6b1"></script>
 </body>
 </html>

package/dist/public/dashboard/styles.css

@@ -4336,24 +4336,33 @@ button.api-filter-clear svg {
   outline: none;
 }
 /* A heading is a link to its own address, in the heading's own ink, with a link icon in the
-   margin to its left while it is hovered or focused, as GitHub's headings show theirs. */
-a.api-self {
+   margin to its left while it is hovered or focused, as GitHub's headings show theirs. The
+   API reference's headings and the Settings sections' titles wear the same. The icon's padding
+   runs its box up to the text, so moving between the two never leaves the link: no gap for the
+   cursor to change in or the icon to vanish in. */
+a.api-self,
+a.set-sec-link {
   position: relative;
   color: inherit;
   text-decoration: none;
 }
-a.api-self svg {
+a.api-self svg,
+a.set-sec-link svg {
   position: absolute;
   left: -20px;
   top: 50%;
-  width: 14px;
+  box-sizing: border-box;
+  width: 20px;
   height: 14px;
+  padding-right: 6px;
   transform: translateY(-50%);
-  color: var(--muted);
+  fill: var(--muted);
   opacity: 0;
 }
 a.api-self:hover svg,
-a.api-self:focus-visible svg {
+a.api-self:focus-visible svg,
+a.set-sec-link:hover svg,
+a.set-sec-link:focus-visible svg {
   opacity: 1;
 }
 .api-op-call {
@@ -5135,6 +5144,13 @@ button.copied svg {
   .set-sec-head {
     scroll-margin-top: 60px;
   }
+  /* The page's gutter here is narrower than the link icon's place in the margin. */
+  a.set-sec-link svg {
+    left: -15px;
+    width: 15px;
+    height: 12px;
+    padding-right: 3px;
+  }
 }
 .set-sec-title {
   margin: 0;
@@ -6253,9 +6269,8 @@ button.set-embed-copy svg {
    here — only safe container defaults. */
 /* The sample email renders in an isolated <iframe> — so the template's own <style>
    block applies exactly as it would in a mail client and can't leak into the
-   dashboard, and the reading measure is constrained to the email column
-   (~640px, matching the view-in-browser render). Its height is sized to content
-   from script. */
+   dashboard, and the document inside draws the email's page and column. Its height
+   is sized to content from script. */
 .set-email-frame {
   display: block;
   width: 100%;
@@ -6265,19 +6280,42 @@ button.set-embed-copy svg {
 }
 
 /* --- Template page: sample-email header actions, dropdown, variables --- */
+/* The bar stays one row at every width: the titles wrap beside the controls, and the toggle
+   gives way in the two steps below, so narrowing the pane changes the layout only there. */
+.set-tpl-sample {
+  container-type: inline-size;
+}
+/* A tablet's pane: the toggle keeps its use, since Phone still looks different, but only its
+   icons, so the bar stays one row. */
+@container (max-width: 640px) {
+  .set-tpl-sample .wtog-lbl {
+    display: none;
+  }
+}
+/* A pane this narrow is close to a phone's width already, so Desktop and Phone would look
+   alike, and the toggle goes. */
+@container (max-width: 480px) {
+  .set-tpl-sample .set-wtog {
+    display: none;
+  }
+  .set-email-stage .set-email-frame.phone {
+    max-width: 100%;
+  }
+}
 .set-preview-titles {
   display: flex;
+  flex: 1 1 0;
   flex-direction: column;
   gap: 1px;
   min-width: 0;
 }
 .set-preview-actions {
   display: flex;
+  flex: 0 0 auto;
   align-items: center;
   gap: 8px;
-  flex-wrap: wrap;
 }
-/* Preview width toggle (640 / 375) — proof both inbox measures; 640 is the default. */
+/* Preview width toggle — proof both inbox measures; Desktop is the default. */
 .set-wtog {
   display: inline-flex;
   gap: 2px;
@@ -6379,25 +6417,27 @@ button.set-embed-copy svg {
 .set-req-pill.bad .dot {
   background: var(--danger-fg);
 }
-/* The sample email sits on a sunken stage so the (width-capped) email card reads as a
-   message on a surface; the width toggle sets its max-width. */
+/* The sample email fills its pane, as a post's Preview does, since an email arrives as a page
+   and not as a card on a surface. So the stage shows only beside the width toggle's Phone, where
+   its color says the frame ends there. --chip, since --sunken is all but the email's own page
+   in dark mode. */
 .set-email-stage {
   display: flex;
   justify-content: center;
-  padding: 16px;
-  background: var(--sunken);
+  background: var(--chip);
 }
 .set-email-stage .set-email-frame {
   width: 100%;
-  max-width: 640px;
+  max-width: 100%;
   /* Floor the auto-sized frame at the default template's height, so emptying or
      shortening the template doesn't collapse the preview and yank the page scroll
-     (the frame can still grow taller for a longer template or the 375 measure). */
-  min-height: 392px;
-  border-radius: 6px;
-  box-shadow: 0 1px 4px rgba(15, 18, 25, 0.1);
+     (the frame can still grow taller for a longer template or the Phone measure). */
+  min-height: 452px;
   transition: max-width 0.16s ease;
 }
+.set-email-stage .set-email-frame.phone {
+  max-width: 375px;
+}
 /* "Start from example": the trigger of a shared menu (openMenu). */
 .set-menu-btn {
   display: inline-flex;
@@ -6609,12 +6649,14 @@ button.set-embed-copy svg {
 .set-rp .set-wtog {
   flex: 0 0 auto;
 }
-.set-rp .wtog-btn {
+.set-rp .wtog-btn,
+.set-tpl-sample .wtog-btn {
   display: inline-flex;
   align-items: center;
   gap: 5px;
 }
-.set-rp .wtog-btn svg {
+.set-rp .wtog-btn svg,
+.set-tpl-sample .wtog-btn svg {
   width: 13px;
   height: 13px;
 }

package/dist/worker/index.js

@@ -1,4 +1,4 @@
-// @kurtbruns/kestrel 1.21.0: the Worker, built by scripts/build-package.mjs.
+// @kurtbruns/kestrel 1.22.0: the Worker, built by scripts/build-package.mjs.
 
 // shared/archive_url.ts
 function archivePostUrl(origin, basePath, slug) {
@@ -993,10 +993,10 @@ var SUBSCRIBER_ACTIONS = {
 
 // src/generated/version.ts
 var BUILD_INFO = {
-  version: "1.21.0",
-  sha: "fd376da",
-  tag: "v1.21.0",
-  buildTime: "2026-11-06T22:01:54.830Z",
+  version: "1.22.0",
+  sha: "eaa6641",
+  tag: "v1.22.0",
+  buildTime: "2026-11-07T06:30:09.521Z",
   repoUrl: "https://github.com/kurtbruns/kestrel"
 };
 
@@ -5103,6 +5103,11 @@ var ERROR_BODY = [
     type: '"access_not_configured" | "access_unidentified"',
     description: "On `unauthorized` only, when signing in again can't help: `access_not_configured`, the deployment has no Cloudflare Access yet, so no request can sign in; `access_unidentified`, Access let the sign-in through but sent neither a person's email nor a service token, so its Access policies need changing. Any other 401 carries none."
   },
+  {
+    name: "dev_token_available",
+    type: "boolean",
+    description: "On `unauthorized` only, and only on a local dev server, where it is `true`: a client may mint a dev token and try again. Absent everywhere else, where no dev route exists."
+  },
   {
     name: "retry_after",
     type: "epoch ms",
@@ -6471,7 +6476,11 @@ var requireAuth = async (c) => {
   const principal = await authenticate(c.req, c.env, c.config);
   if (!principal || principal === "access_unidentified") {
     const reason = principal ?? lockedReason(c.config);
-    const body = reason ? { error: "unauthorized", message: UNAUTHORIZED_MESSAGE[reason], reason } : { error: "unauthorized", message: SIGN_IN_MESSAGE };
+    const body = reason ? { error: "unauthorized", message: UNAUTHORIZED_MESSAGE[reason], reason } : {
+      error: "unauthorized",
+      message: SIGN_IN_MESSAGE,
+      ...c.config.devMode ? { dev_token_available: true } : {}
+    };
     return json(body, 401, { "WWW-Authenticate": 'Bearer realm="kestrel"' });
   }
   const client = c.req.headers.get(CLIENT_HEADER);
@@ -7085,6 +7094,9 @@ function unavailablePage() {
   res.headers.set("retry-after", "300");
   return res;
 }
+function asksForHtml(req) {
+  return (req.headers.get("accept") ?? "").includes("text/html");
+}
 function serverErrorPage() {
   return messagePage({
     identity: { name: "" },
@@ -7304,17 +7316,22 @@ function guard(access, res) {
 }
 var Router = class {
   /** `readerPage` says whether a path is one a reader opens in a browser, where an error
-   *  nothing handled is answered with a page rather than JSON. */
-  constructor(readerPage2 = () => false) {
+   *  nothing handled is answered with a page rather than JSON; `notFoundPage` is what a browser
+   *  gets there for an address that names no page. */
+  constructor(readerPage2 = () => false, notFoundPage) {
     this.readerPage = readerPage2;
+    this.notFoundPage = notFoundPage;
   }
   readerPage;
+  notFoundPage;
   compiled = [];
   /** Register a route from its manifest entry; the `access` tier decides the gate. */
   register(def) {
     const strict = def.access !== "webhook" && !this.readerPage(def.path) ? [refuseUndeclared(def)] : [];
     const middleware = [...gateFor(def), ...strict, ...def.middleware ?? []];
-    this.compiled.push({ def, pattern: new URLPattern({ pathname: def.path }), middleware });
+    const slash = def.access === "public" && this.readerPage(def.path) && !def.path.endsWith("/");
+    const pathname = slash ? `${def.path}{/}?` : def.path;
+    this.compiled.push({ def, pattern: new URLPattern({ pathname }), middleware });
     return this;
   }
   /**
@@ -7351,10 +7368,10 @@ var Router = class {
         continue;
       }
       const { params, error: badParam } = decodePathParams(match.pathname.groups);
-      const c = { req, env, ctx, url, params, config };
+      const c2 = { req, env, ctx, url, params, config };
       try {
         for (const mw of route2.middleware) {
-          const short = await mw(c);
+          const short = await mw(c2);
           if (short) {
             return guard(route2.def.access, short);
           }
@@ -7362,16 +7379,35 @@ var Router = class {
         if (badParam) {
           throw badParam;
         }
-        return guard(route2.def.access, await route2.def.handler(c));
+        return guard(route2.def.access, await route2.def.handler(c2));
       } catch (err) {
         if (!(err instanceof HttpError) && this.readerPage(url.pathname)) {
           logUncaught(err);
           return guard(route2.def.access, serverErrorPage());
         }
-        return guard(route2.def.access, toErrorResponse(err));
+        const noPage = err === badParam || err instanceof HttpError && err.code === "not_found";
+        const page = noPage ? await this.noSuchPage(c2) : void 0;
+        return guard(route2.def.access, page ?? toErrorResponse(err));
       }
     }
-    return json({ error: "not_found" }, 404);
+    const c = { req, env, ctx, url, params: {}, config };
+    return await this.noSuchPage(c) ?? json({ error: "not_found" }, 404);
+  }
+  /**
+   * The reader's page for an address that names none, when a browser asked for it on a reader
+   * path (SPEC §5); `undefined` leaves the JSON, which the API's clients read and anything not
+   * asking for a page may. A failure here is one nothing handled, so it gets that page.
+   */
+  async noSuchPage(c) {
+    if (!this.notFoundPage || !this.readerPage(c.url.pathname) || !asksForHtml(c.req)) {
+      return void 0;
+    }
+    try {
+      return await this.notFoundPage(c);
+    } catch (err) {
+      logUncaught(err);
+      return serverErrorPage();
+    }
   }
 };
 
@@ -9160,6 +9196,16 @@ function nothingHereYetPage(c) {
     status: 404
   });
 }
+function noPageHerePage(c) {
+  return readerMessage(c, {
+    title: "No page here",
+    eyebrow: "Not found",
+    headline: "No page here",
+    ledeHtml: "There\u2019s no page at this address.",
+    afterHtml: archiveLink(archiveHomeUrl(c.config), "Browse the archive"),
+    status: 404
+  });
+}
 async function postPage(c, post, send) {
   const html = webVersion(send.rendered_html, {
     config: c.config,
@@ -9403,11 +9449,43 @@ function probeImageDimensions(b) {
     return { width: dv.getUint32(16), height: dv.getUint32(20) };
   }
   if (b[0] === 71 && b[1] === 73 && b[2] === 70 && b[3] === 56) {
-    return { width: dv.getUint16(6, true), height: dv.getUint16(8, true) };
+    const width = dv.getUint16(6, true);
+    const height = dv.getUint16(8, true);
+    return width && height ? { width, height } : null;
   }
   if (b[0] === 255 && b[1] === 216) {
     return probeJpeg(b, dv);
   }
+  if (fourCc(b, 0) === "RIFF" && fourCc(b, 8) === "WEBP") {
+    return probeWebp(b, dv);
+  }
+  return null;
+}
+function fourCc(b, offset) {
+  return String.fromCharCode(...b.subarray(offset, offset + 4));
+}
+function probeWebp(b, dv) {
+  const chunk3 = fourCc(b, 12);
+  if (chunk3 === "VP8 ") {
+    if (b.length < 30 || b[23] !== 157 || b[24] !== 1 || b[25] !== 42) {
+      return null;
+    }
+    return { width: dv.getUint16(26, true) & 16383, height: dv.getUint16(28, true) & 16383 };
+  }
+  if (chunk3 === "VP8L") {
+    if (b.length < 25 || b[20] !== 47) {
+      return null;
+    }
+    const sizes = dv.getUint32(21, true);
+    return { width: (sizes & 16383) + 1, height: (sizes >>> 14 & 16383) + 1 };
+  }
+  if (chunk3 === "VP8X") {
+    if (b.length < 30) {
+      return null;
+    }
+    const canvasSize = (at) => (dv.getUint16(at, true) | dv.getUint8(at + 2) << 16) + 1;
+    return { width: canvasSize(24), height: canvasSize(27) };
+  }
   return null;
 }
 function probeJpeg(b, dv) {
@@ -9419,7 +9497,9 @@ function probeJpeg(b, dv) {
     }
     const marker = b[off + 1];
     if (marker !== void 0 && marker >= 192 && marker <= 207 && marker !== 196 && marker !== 200 && marker !== 204) {
-      return { width: dv.getUint16(off + 7), height: dv.getUint16(off + 5) };
+      const width = dv.getUint16(off + 7);
+      const height = dv.getUint16(off + 5);
+      return width > 0 && height === 0 ? null : { width, height };
     }
     const len = dv.getUint16(off + 2);
     if (len < 2) {
@@ -13364,7 +13444,7 @@ var notifications_default = "# Notifications through Cloudflare's email\n\nKestr
 var rate_limit_default = "# Rate-limit the subscribe form\n\nThe subscribe form is public, so anyone can submit it, as often as they like. The app already sends any one address at most one confirmation every 15 minutes, and answers every address the same way. It can't tell one visitor from another, though. Cloudflare can, so a rule at Cloudflare caps how often each visitor submits.\n\nIn this guide, you add a rate-limiting rule for the subscribe page, and check that it blocks a burst of requests. Nothing changes in the app.\n\n## 1. Add a rate-limiting rule\n\nCloudflare's Free plan includes one rate-limiting rule, and the subscribe form is a good place to spend it.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), open your domain, `example.com`, and go to **Security rules**.\n\n1. Select **Create rule**, then **Rate limiting rules**.\n\n1. Fill in the rule:\n\n    - **Rule name:** `Subscribe form`\n    - **If incoming requests match:** **URI Path** equals `/subscribe`\n    - **With the same characteristics:** IP\n    - **When rate exceeds:** 5 requests per 10 seconds\n    - **Then take action:** Block, with a duration of 10 seconds\n\n    The rule's expression reads:\n\n    ```\n    (http.request.uri.path eq \"/subscribe\")\n    ```\n\n1. Select **Deploy**.\n\nOn the Free plan, a rule can match only on the path. It counts loads of the form as well as submissions, and `/subscribe` on every hostname in your domain. At five requests in 10 seconds, neither gets in a real reader's way.\n\nA paid plan allows a longer window, which fits a form better. On Pro, try 10 requests a minute, blocked for 10 minutes. Pro can also limit the rule to the app's hostname, with `and http.host eq \"newsletter.example.com\"`. Business can limit it to submissions, with `and http.request.method eq \"POST\"`.\n\nThe rule covers only your domain's hostnames. The Worker's `workers.dev` addresses would skip it, which is why your production settings keep `workers_dev` and `preview_urls` set to `false`. Keep them that way.\n\n## Check it\n\n1. Request the subscribe page eight times in a row:\n\n    ```bash\n    for i in $(seq 1 8); do curl -s -o /dev/null -w \"%{http_code}\\n\" https://newsletter.example.com/subscribe; done\n    ```\n\n    The first requests answer `200`. Once you pass five within 10 seconds, the rest answer `429`, Cloudflare's block. The switch can come a request or two later.\n\n1. Wait 10 seconds, and open `https://newsletter.example.com/subscribe` in a browser. The form loads again.\n\n1. In the dashboard, **Security rules** lists `Subscribe form` as active.\n";
 
 // docs/guides/07-upgrade.md
-var upgrade_default = "# Upgrade to a new release\n\nA new release of Kestrel is a new version of the `@kurtbruns/kestrel` package. Upgrading changes the version your instance's repository names, brings in the release's database changes, and deploys. The app can't undo a database change, so you note a restore point first.\n\nIn this guide, you read what changed, install the release, and note where your database stands. Then you apply the database changes, deploy, and check the new version. If you run a staging environment, upgrade it first, and repeat each step for production once it checks out.\n\n## 1. Read what changed\n\nA release can ask you to change a setting or a record before it runs. The changelog says so, release by release.\n\n1. Find the version you run. In the editor, open the **Docs** or **API** tab. The foot of its contents list shows the version, then the commit. Your instance's `package.json` names it too, as the version of `@kurtbruns/kestrel`.\n\n1. Read the [release notes](https://github.com/kurtbruns/kestrel/releases) for every version after yours, up to the one you're moving to. Each release opens with an **Upgrading from\u2026** paragraph that says what to do. Its **Breaking** entries say what changed underneath you.\n\n## 2. Install the release\n\nEach step here changes only your instance's repository. Nothing reaches your deployed app until section 5.\n\n1. Start from a clean repository, so the upgrade's commit holds only the upgrade and going back undoes nothing else:\n\n    ```bash\n    git status\n    ```\n\n    If it lists anything, commit it first, as its own commit, or move it out of the repository.\n\n1. Install the release. Replace `X.Y.Z` with its version:\n\n    ```bash\n    npm install @kurtbruns/kestrel@X.Y.Z\n    ```\n\n    Your `package.json` now names exactly that version. Kestrel's versions aren't semantic versioning, so your instance never moves to a release you didn't choose.\n\n    If npm stops with `ERESOLVE` and names wrangler, your `package.json` pins a wrangler older than the release needs. The error's `peer wrangler@` line gives the range it needs. Install both together, with that range in place of `WRANGLER_RANGE`:\n\n    ```bash\n    npm install @kurtbruns/kestrel@X.Y.Z \"wrangler@WRANGLER_RANGE\"\n    ```\n\n1. Bring in the release's database migrations:\n\n    ```bash\n    npm run sync-migrations\n    ```\n\n    It copies each new migration into `migrations/` and names the ones it added. It never overwrites one that's there.\n\n1. Check the Claude Code files Kestrel gave your instance:\n\n    ```bash\n    npm run check-context\n    ```\n\n    It compares each file in `.claude/` with the release's, and says what to do for each one:\n\n    - **current**: nothing to do.\n    - **Kestrel changed it, and you haven't edited it**: take the new one with `npm run check-context -- --update`.\n    - **Kestrel changed it, and you've edited it**: it shows the difference from yours to the release's. Merge what you want into yours, by hand or with Claude, then record that you did with the command it prints.\n\n1. If the release's **Upgrading from\u2026** paragraph names a new setting, add it to `wrangler.jsonc`.\n\n1. Check the configuration and the types:\n\n    ```bash\n    npm run typecheck\n    ```\n\n1. **(Optional)** Try the release on your computer. Apply its database changes to your local database, then start the app:\n\n    ```bash\n    npx wrangler d1 migrations apply DB --local\n    npm run dev\n    ```\n\n    You see the new version with your local content. It can't show how the changes treat your real data. A staging environment can.\n\n1. Commit the upgrade as one commit, and push it. Going back, below, undoes this commit:\n\n    ```bash\n    git add -A\n    git commit -m \"Upgrade Kestrel to X.Y.Z\"\n    git push\n    ```\n\n## 3. Note a restore point\n\nD1 keeps a history of your database, called Time Travel, for 30 days on Workers Paid and 7 on Workers Free. A bookmark marks one moment in it, so you can put the database back if the upgrade goes wrong.\n\n1. In the editor, check that no send is in progress. The dashboard lists any that are. Upgrade between sends.\n\n1. Note where the database stands now:\n\n    ```bash\n    npx wrangler d1 time-travel info DB --env production\n    ```\n\n    It prints a bookmark for the database's current state. Copy it, and keep it until the upgrade checks out.\n\n## 4. Apply the database changes\n\nA release changes the database only by adding a migration. Applying it keeps everything already in the database.\n\n```bash\nnpx wrangler d1 migrations apply DB --remote --env production\n```\n\nIt lists the migrations it's about to apply, and asks you to confirm. Run by Claude, or in any other shell that isn't interactive, it answers its own prompt and applies them without asking. When a release has none, it says there's nothing to apply. Run it on every upgrade.\n\n## 5. Deploy\n\n```bash\nnpx wrangler deploy --env production\n```\n\nNear its end, the output names your app's hostname, then its schedule and a version ID.\n\n## Check it\n\n1. The app answers:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {\"status\":\"ok\",\"service\":\"kestrel\"}\n    ```\n\n    If it answers `500` with `{\"error\":\"schema_behind\",\"missing\":[\u2026],\u2026}` instead, the release was deployed before its database changes: the public pages say the newsletter is temporarily unavailable and nothing is sent. Apply them as in section 4; the app answers as soon as they're applied, with no new deploy.\n\n1. Reload the editor. The foot of the **Docs** tab's contents list shows the new version, which links to its release page.\n\n1. Send yourself a test email, as in [Verify it works](../get-started/07-verify.md#1-send-yourself-a-test-email). Don't send a real post to check an upgrade: on a live instance, it goes to your whole list.\n\n1. In the logs, `sweep.tick` still arrives every minute, as in [Verify it works](../get-started/07-verify.md#7-read-the-logs).\n\n## Go back\n\nIf the new release misbehaves, deploy the previous one, and put the database back to your bookmark.\n\n1. Find the upgrade's commit. Replace `X.Y.Z` with the release you're backing out. Its id comes first on the line:\n\n    ```bash\n    git log -1 --oneline --grep=\"Upgrade Kestrel to X.Y.Z\"\n    ```\n\n1. Undo it. This adds a commit that puts back the previous release, its migrations, and your Claude Code files, and leaves anything you committed since as it is:\n\n    ```bash\n    git revert --no-edit REPLACE_WITH_COMMIT_ID\n    ```\n\n1. Install the previous release, and deploy it:\n\n    ```bash\n    npm ci\n    npx wrangler deploy --env production\n    ```\n\n1. Restore the database to the bookmark from section 3:\n\n    ```bash\n    npx wrangler d1 time-travel restore DB --env production --bookmark=REPLACE_WITH_BOOKMARK\n    ```\n\n1. Push the revert to your repository:\n\n    ```bash\n    git push\n    ```\n\nA restore returns the whole database to that moment. Everything written since is gone: edits to posts, new subscribers, and the record of anything sent. Restore only soon after the upgrade.\n\nNever restore past a send that went out, or an unsubscribe recorded since the bookmark. The restored database wouldn't know of them, so it could mail those readers again, or mail someone who left. If either happened, stay on the new release, and fix forward.\n";
+var upgrade_default = "# Upgrade to a new release\n\nA new release of Kestrel is a new version of the `@kurtbruns/kestrel` package. Upgrading changes the version your instance's repository names, brings in the release's database changes, and deploys. The app can't undo a database change, so you note a restore point first.\n\nIn this guide, you first read what changed and check that your repository is clean, which changes nothing. Then you install the release, note where your database stands, apply the database changes, deploy, and check the new version. If you run a staging environment, upgrade it first, and repeat each step for production once it checks out.\n\n## 1. Check before you change anything\n\nA release can ask you to change a setting or a record before it runs. The changelog says so, release by release. The upgrade also has to start from a clean repository.\n\n1. Find the version you run. In the editor, open the **Docs** or **API** tab. The foot of its contents list shows the version, then the commit. Your instance's `package.json` names it too, as the version of `@kurtbruns/kestrel`.\n\n1. Read the [release notes](https://github.com/kurtbruns/kestrel/releases) for every version after yours, up to the one you're moving to. Each release opens with an **Upgrading from\u2026** paragraph that says what to do. Its **Breaking** entries say what changed underneath you.\n\n1. Check that your repository is clean, so the upgrade's commit holds only the upgrade and going back undoes nothing else:\n\n    ```bash\n    git status\n    ```\n\n    It has to say `nothing to commit, working tree clean`. If it lists anything, untracked files included, the upgrade waits until it doesn't.\n\nNothing has changed yet. If you aren't going on, stop here.\n\n## 2. Install the release\n\nEach step here changes only your instance's repository. Nothing reaches your deployed app until section 5.\n\n1. Install the release. Replace `X.Y.Z` with its version:\n\n    ```bash\n    npm install @kurtbruns/kestrel@X.Y.Z\n    ```\n\n    Your `package.json` now names exactly that version. Kestrel's versions aren't semantic versioning, so your instance never moves to a release you didn't choose.\n\n    If npm stops with `ERESOLVE` and names wrangler, your `package.json` pins a wrangler older than the release needs. The error's `peer wrangler@` line gives the range it needs. Install both together, with that range in place of `WRANGLER_RANGE`:\n\n    ```bash\n    npm install @kurtbruns/kestrel@X.Y.Z \"wrangler@WRANGLER_RANGE\"\n    ```\n\n1. Bring in the release's database migrations:\n\n    ```bash\n    npm run sync-migrations\n    ```\n\n    It copies each new migration into `migrations/` and names the ones it added. It never overwrites one that's there.\n\n1. Check the Claude Code files Kestrel gave your instance:\n\n    ```bash\n    npm run check-context\n    ```\n\n    It compares each file in `.claude/` with the release's, and says what to do for each one:\n\n    - **current**: nothing to do.\n    - **Kestrel changed it, and you haven't edited it**: take the new one with `npm run check-context -- --update`.\n    - **Kestrel changed it, and you've edited it**: it shows the difference from yours to the release's. Merge what you want into yours, by hand or with Claude, then record that you did with the command it prints.\n\n1. If the release's **Upgrading from\u2026** paragraph names a new setting, add it to `wrangler.jsonc`.\n\n1. Check the configuration and the types:\n\n    ```bash\n    npm run typecheck\n    ```\n\n1. **(Optional)** Try the release on your computer. Apply its database changes to your local database, then start the app:\n\n    ```bash\n    npx wrangler d1 migrations apply DB --local\n    npm run dev\n    ```\n\n    You see the new version with your local content. It can't show how the changes treat your real data. A staging environment can.\n\n1. Commit the upgrade as one commit, and push it. Going back, below, undoes this commit:\n\n    ```bash\n    git add -A\n    git commit -m \"Upgrade Kestrel to X.Y.Z\"\n    git push\n    ```\n\n## 3. Note a restore point\n\nD1 keeps a history of your database, called Time Travel, for 30 days on Workers Paid and 7 on Workers Free. A bookmark marks one moment in it, so you can put the database back if the upgrade goes wrong.\n\n1. In the editor, check that no send is in progress. The dashboard lists any that are. Upgrade between sends.\n\n1. Note where the database stands now:\n\n    ```bash\n    npx wrangler d1 time-travel info DB --env production\n    ```\n\n    It prints a bookmark for the database's current state. Copy it, and keep it until the upgrade checks out.\n\n## 4. Apply the database changes\n\nA release changes the database only by adding a migration. Applying it keeps everything already in the database.\n\n```bash\nnpx wrangler d1 migrations apply DB --remote --env production\n```\n\nIt lists the migrations it's about to apply, and asks you to confirm. Run by Claude, or in any other shell that isn't interactive, it answers its own prompt and applies them without asking. When a release has none, it says there's nothing to apply. Run it on every upgrade.\n\n## 5. Deploy\n\n```bash\nnpx wrangler deploy --env production\n```\n\nNear its end, the output names your app's hostname, then its schedule and a version ID.\n\n## Check it\n\n1. The app answers:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {\"status\":\"ok\",\"service\":\"kestrel\"}\n    ```\n\n    If it answers `500` with `{\"error\":\"schema_behind\",\"missing\":[\u2026],\u2026}` instead, the release was deployed before its database changes: the public pages say the newsletter is temporarily unavailable and nothing is sent. Apply them as in section 4; the app answers as soon as they're applied, with no new deploy.\n\n1. Reload the editor. The foot of the **Docs** tab's contents list shows the new version, which links to its release page.\n\n1. Send yourself a test email, as in [Verify it works](../get-started/07-verify.md#1-send-yourself-a-test-email). Don't send a real post to check an upgrade: on a live instance, it goes to your whole list.\n\n1. In the logs, `sweep.tick` still arrives every minute, as in [Verify it works](../get-started/07-verify.md#7-read-the-logs).\n\n## Go back\n\nIf the new release misbehaves, deploy the previous one, and put the database back to your bookmark.\n\n1. Find the upgrade's commit. Replace `X.Y.Z` with the release you're backing out. Its id comes first on the line:\n\n    ```bash\n    git log -1 --oneline --grep=\"Upgrade Kestrel to X.Y.Z\"\n    ```\n\n1. Undo it. This adds a commit that puts back the previous release, its migrations, and your Claude Code files, and leaves anything you committed since as it is:\n\n    ```bash\n    git revert --no-edit REPLACE_WITH_COMMIT_ID\n    ```\n\n1. Install the previous release, and deploy it:\n\n    ```bash\n    npm ci\n    npx wrangler deploy --env production\n    ```\n\n1. Restore the database to the bookmark from section 3:\n\n    ```bash\n    npx wrangler d1 time-travel restore DB --env production --bookmark=REPLACE_WITH_BOOKMARK\n    ```\n\n1. Push the revert to your repository:\n\n    ```bash\n    git push\n    ```\n\nA restore returns the whole database to that moment. Everything written since is gone: edits to posts, new subscribers, and the record of anything sent. Restore only soon after the upgrade.\n\nNever restore past a send that went out, or an unsubscribe recorded since the bookmark. The restored database wouldn't know of them, so it could mail those readers again, or mail someone who left. If either happened, stay on the new release, and fix forward.\n";
 
 // docs/guides/09-as-your-list-grows.md
 var as_your_list_grows_default = "# As your list grows\n\nA new instance runs on Cloudflare's free Workers plan with your starting Amazon SES limits. Workers Free suits a list of up to about 1,000 subscribers. Past about 5,000, one send can use up the day's database writes and stop the newsletter until midnight UTC. As the list grows, two limits start to matter: how fast a send goes out, and how many database writes the free plan allows a day.\n\nIn this guide, you raise your SES limits, which helps on either plan, and upgrade to Workers Paid, which a larger list needs. Then you see how long a send takes after each.\n\n## 1. Raise your SES limits\n\nSES caps how many emails your account sends a day, and how many a second. A send that hits the daily quota waits, emails you, and resumes on its own once the quota frees up. Raising your maximum send rate to 50 a second costs nothing, and it makes every send faster.\n\n1. Ask AWS for a higher daily quota and a maximum send rate of 50, as AWS's [Increasing your Amazon SES sending quotas](https://docs.aws.amazon.com/ses/latest/dg/manage-sending-quotas-request-increase.html) describes.\n\n1. When AWS grants it, the app takes the new rate from your account within about ten minutes, and **Settings \u2192 Email sender** shows it under **Send rate**. If `SES_MAX_SEND_RATE` is set in `wrangler.jsonc`, the app keeps to the lower of the two, so remove it or raise it to match, then deploy, as [Configuration](../reference/01-configuration.md#vars) describes.\n\n## 2. Upgrade to Workers Paid\n\nCloudflare's $5 Workers Paid plan helps in two ways, at any size of list.\n\n- **Faster sends.** On the free plan, Cloudflare caps how much one minute's work can do. A send then uses your SES rate for only a few seconds of each minute: about 56 emails a minute at a rate of 14. On Workers Paid, a send uses about 50 seconds of each minute, about 700 emails a minute at the same rate. If sends feel slow, upgrading speeds them up more than raising your SES rate does. [How long a send takes](#how-long-a-send-takes) compares them.\n- **No daily limit on database writes.** On the free plan, [D1](https://developers.cloudflare.com/d1/platform/pricing/) allows 100,000 written rows a day, reset at midnight UTC. A send writes about 14 rows a recipient, receipts included, and an import about 7 for each new subscriber. So at 1,000 subscribers, an import of the whole list and two sends on one day use about a third of the day. Once the day's rows are spent, the whole app stops until midnight UTC, the SES webhook with it. That day's bounces and complaints are lost, and suppress or unsubscribe no one.\n\n    It's recommended to upgrade from about 1,000 subscribers. Past that, the Dashboard and the Subscribers screen say so, and so does an import that would take the list past it. Past about 5,000, a send that could use up the day on its own also warns before it's scheduled. The app doesn't count the day's writes, so between the two, two large sends or several imports and a send on one UTC day can still use it up without a warning at that moment.\n\n1. Upgrade your Cloudflare account to the $5 [Workers Paid plan](https://developers.cloudflare.com/workers/platform/pricing/), which has no daily limit on writes.\n\n1. In `wrangler.jsonc`, add `\"SUBREQUEST_BUDGET\": \"10000\"` to the `production` block's `vars`. It tells the app it's on Workers Paid, so each minute sends far more. [Configuration](../reference/01-configuration.md#vars) describes `SUBREQUEST_BUDGET`.\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am \"Run on Workers Paid\"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\nOver years, one more limit can matter: on the free plan, one [D1 database](https://developers.cloudflare.com/d1/platform/limits/) holds at most 500 MB, and every send keeps a row for each recipient in its record. Workers Paid raises it to 10 GB.\n\n## How long a send takes\n\n| Setup | 1,000 subscribers | 5,000 subscribers | 10,000 subscribers |\n| --- | --- | --- | --- |\n| Free plan, a starting SES rate of 14 | about 18 minutes | about 1.5 hours | over the free plan's daily writes |\n| Free plan, SES rate raised to 50 | about 5 minutes | about 25 minutes | over the free plan's daily writes |\n| Workers Paid, SES rate of 14 | about 2 minutes | about 7 minutes | about 15 minutes |\n| Workers Paid, SES rate of 50 | under a minute | about 2 minutes | about 4 minutes |\n\n## Check it\n\n1. **Settings \u2192 Email sender** shows your new maximum send rate under **Send rate**, \"from your SES account\".\n\n1. On Workers Paid, the import screen under **Subscribers \u2192 Import** reads \"CSV or .txt, up to 10,000 rows.\"\n";
@@ -13412,7 +13492,7 @@ The From name and address your emails come from are set when Kestrel is deployed
 var write_a_post_default = "# Write and send a post\n\nWrite in Markdown, schedule it, then send yourself a test. Scheduling makes the exact email your list will get, so the test you send is what goes out.\n\n**New post**, on the Dashboard or under **Drafts**, opens a draft.\n\n## Write\n\nThe editor takes Markdown, and Kestrel saves as you type. The same Markdown becomes the email, in your [email template](11-email-template.md), and the post's page in your archive. **Preview** shows the email, and warns under it about anything it found wrong.\n\n- A blank line starts a new paragraph.\n- The opening lines are the preview a mail client shows beside the subject.\n- Paste or drop an image to add it: PNG, JPEG, WebP, or GIF, up to 5 MB. A file named for a different format than it really is, like a JPEG called `photo.png`, is refused until you rename it. Kestrel may change its file name, turning spaces into hyphens and numbering a name the post already has, and inserts the new name for you.\n\n## Schedule and send\n\nChoose **Schedule**, pick a time under **Send at**, and confirm. The time must be at least five minutes away by default, or the lead whoever runs your instance set. That's your window to catch a mistake, and you can cancel or move the send until then. **Send now** sends after the same wait.\n\n**Then send yourself a test.** Scheduling locks the post and makes its email, so **Send test email** now sends exactly what your list receives. **Settings \u2192 Default test recipients** fills in the addresses. A test needs an email provider, which [Connect Amazon SES](../get-started/05-ses.md) sets up.\n\nTo change the post, choose **Cancel** on its banner, and it's a draft again. **Edit schedule** moves the time without unlocking it.\n\nAt the send time, the post goes to your confirmed subscribers, and its page goes up in your archive. Watch it go out under **Sent**. If a send needs you, its page says so, and [Troubleshooting](06-troubleshooting.md) covers each case.\n\n## Post settings\n\n**Post settings**, at the top right of the editor, holds two choices you can change until the post sends:\n\n- **Include in archive.** Uncheck it to send the post as email only, for a correction or a short notice. It stays off your archive and home page.\n- **Archive address.** It follows the subject until you type your own. It's fixed once the post sends.\n\nAfter a post sends, its page under **Sent** can take it out of your archive or put it back.\n";
 
 // docs/publishing/06-troubleshooting.md
-var troubleshooting_default = "# Troubleshooting\n\nWhen something needs you, Kestrel says so in a line on the send's page, under **Sent**. The top of the dashboard shows it too. Red needs you to act, and amber is worth a look. The line says what happened and what to do. This page covers what the screen can't: the fixes made outside Kestrel, and the decisions that are yours.\n\n**Set a notifications address, so a problem reaches you without your watching.** Set it under **Settings \u2192 Notifications**, in **Send notifications to**: type an address and choose **Add inbox**. Add the address of whoever runs your instance too, and both of you are told. With none set, Kestrel emails you nothing. [Notifications](#notifications), below, lists what you're told.\n\n| Symptom | Where the fix is |\n| --- | --- |\n| [A send is held or waiting](#a-send-is-held-or-waiting) | Usually outside Kestrel |\n| [Someone was mailed twice, or not at all](#someone-was-mailed-twice-or-not-at-all) | In Kestrel |\n| [A reader says they never got a post](#a-reader-says-they-never-got-a-post) | In Kestrel |\n| [A send still reads Settling](#a-send-still-reads-settling) | Nothing to fix, unless no receipts come at all |\n| [A test doesn't arrive](#a-test-doesnt-arrive) | Outside Kestrel |\n| [Signups aren't open yet, or are paused](#signups-arent-open-yet-or-are-paused) | In Kestrel, or outside it |\n| [The dashboard names a problem with your Amazon SES account](#a-problem-with-amazon-ses) | Outside Kestrel |\n| [An address bounced or complained](#an-address-bounced-or-complained) | Nothing to fix, unless you lift a suppression |\n| [A warning says to move to Workers Paid](../guides/09-as-your-list-grows.md) | Outside Kestrel |\n| [An import is refused](#an-import-is-refused) | In your file |\n| [Claude can't connect](#claude-cant-connect) | Usually outside Kestrel |\n\n## A send is held or waiting\n\nNothing is lost. A problem with your email provider never marks anyone unsent or mails anyone twice. The send waits where it is, and carries on once the problem is fixed. The send's line names the fix. When that fix is outside Kestrel, it's one of these:\n\n- **Amazon SES refuses your account or the send.** The line carries SES's words and the fix, almost always in the SES console. [Connect Amazon SES](../get-started/05-ses.md) sets up each piece SES checks: the sending domain, the AWS key, and the configuration set. [Request production access](../get-started/06-production-access.md) lifts the sandbox. When SES refuses your account, any other post that comes due meanwhile waits with it. When it refuses only this send's email, other posts go out as usual. While SES takes some readers and refuses the rest, as while a daily quota frees up, those it takes are sent. The line stays until SES takes everyone.\n- **SES keeps refusing for its sending rate.** Kestrel is sending faster than your SES account allows. **Settings \u2192 Email sender** shows the **Send rate** and where it comes from. If `SES_MAX_SEND_RATE` sets it, lower it to the maximum send rate on the SES console's account dashboard, or remove it, then deploy, as [Configuration](../reference/01-configuration.md#vars) describes. If it's Kestrel's default, the app can't read your account: allow its key `ses:GetAccount`, as [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) shows.\n- **No email provider is connected.** Connect one, as [Connect Amazon SES](../get-started/05-ses.md) describes, and the send goes out at its next retry.\n- **A send missed its time, or nothing has gone out for a while.** The part of Kestrel that sends has stopped, or keeps failing on this send. Check the Worker's Cron Trigger, as [Configuration](../reference/01-configuration.md#bindings-and-triggers) describes, and read the app's logs, as [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes. If another send is going out at the same time, this one may only be waiting its turn.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## Someone was mailed twice, or not at all\n\nKestrel never mails a reader twice on its own. When it can't tell whether your provider took some emails, it stops and asks you: the send's page shows **Resolve\u2026**. Choose **Assume not sent** unless you know otherwise, since it's the safe default: those readers may miss this post, but get your next one. Choose **Assume sent** only when you know they got it, such as from a reader who tells you so. Either choice mails no one.\n\nA reader recorded as **Unsent** is still on your list and gets your next post. That send never mails them again: their own email kept failing, SES won't take their address, or you chose **Assume not sent**.\n\n## A reader says they never got a post\n\nUnder **Subscribers**, search for their address and open their row. Their page lists every send they were in, newest first, with what happened on each: **Delivered**, a bounce, a complaint, **Unsent** with your email provider's words, or **Skipped** because they had unsubscribed or were suppressed by then. Each send links to its record. The page also shows how they joined and why they left, if they did. Any bounce or block on the address shows with the provider's words or yours. If they aren't on the list, or are still **pending**, they never confirmed, and only confirmed subscribers are sent your posts.\n\n## A send still reads Settling\n\nThat's normal. **Delivered** counts only the emails your provider confirmed reached the reader's mail server. Confirmations can lag by days, so the counts keep rising after a send finishes. Some are never confirmed at all, so a send can read **Settling** for good, as long as some receipts have come.\n\nWhen none come, the send's page says so an hour after it went out. Your provider's reports aren't reaching Kestrel, so its bounces suppress no one and its complaints unsubscribe no one. Your next post mails those addresses again. Look for `webhook.refused` errors in the app's logs, as [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes. Each names the SNS topic that reached Kestrel and the one it expects. Then check the subscription, as [Connect Amazon SES](../get-started/05-ses.md#7-subscribe-the-app-to-the-topic) describes. If someone else set up Kestrel for you, pass this along to them.\n\n## A test doesn't arrive\n\nWhile Amazon SES is in its sandbox, it mails only addresses verified in SES. Verify the address you test with in the SES console, or [request production access](../get-started/06-production-access.md). When the test's line says the provider didn't answer, check the inbox before you send it again, since the first may have arrived. A test SES refuses for your account has the same fix as [a send it refuses](#a-send-is-held-or-waiting). If someone else set up Kestrel for you, pass this along to them.\n\n## Signups aren't open yet, or are paused\n\nYour subscribe page takes signups only while email is working, so a reader is never told a link is coming when none can go. Every visitor gets the same page, whatever address they enter.\n\n- \"Signups aren\u2019t open yet\" means SES hasn't sent an email for your publication yet. Send one from **Template \u2192 Send test email**, to an address verified in SES while it's in the sandbox. Once SES takes it, signups open. Before an email provider is connected, the page says the same, and [Connect Amazon SES](../get-started/05-ses.md) is the fix.\n- \"Signups are paused\" means SES is refusing your email, every email including confirmations and tests. The dashboard's **Email isn\u2019t going out** line gives SES's words and the fix, as for [a problem with Amazon SES](#a-problem-with-amazon-ses). Then send a test email: once SES takes one, signups reopen.\n\nKestrel notices a refusal when an email meets it, or within about ten minutes from its check of your SES account. A refusal the check found lifts on its own within about ten minutes of the fix; one an email met lifts when a test email goes through. A reader who signed up just as it started may have been told a link was coming, and can sign up again once signups reopen.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## A problem with Amazon SES\n\n**Settings \u2192 Email sender** and the top of the dashboard name a problem with your Amazon SES account within about ten minutes, without sending anything. Red means no email can go out until it's fixed, tests and confirmations included. Amber is worth a look. Each line links the step that fixes it:\n\n- **The configuration set is missing, or its sending is off.** The set Kestrel sends with, the one `SES_CONFIGURATION_SET` names or the sending identity's default if that secret isn't set, isn't in your region, or its sending is turned off. Correct the name, or create the set, as [Connect Amazon SES](../get-started/05-ses.md#4-send-bounces-and-complaints-to-the-app) shows. Turn a set's sending back on in the SES console, under its configuration sets.\n- **SES rejects the AWS key.** The key ID is unknown, the secret doesn't match it, or the AWS account isn't signed up for SES. Store the key's ID and secret again, or create a new key, as [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) shows.\n- **The sender isn't verified.** SES has no verified identity for the From address in your region. Verify the sending hostname, as [Connect Amazon SES](../get-started/05-ses.md#1-verify-your-sending-hostname) shows.\n- **Sending is turned off for the account.** AWS documents turning it back on only with the AWS CLI, naming your region: `aws sesv2 put-account-sending-attributes --sending-enabled --region us-east-1`.\n- **AWS paused the account, or is reviewing it.** AWS does this when the account's bounce or complaint rate runs high. While it reviews, SES still sends, and the line is amber. Once it pauses sending, the line is red. Either way, AWS's email to the AWS account says what it needs: answer it in AWS Support, and check the addresses on your recent sends' records.\n\nThe app needs to read each of these. If its key isn't allowed to, the line says nothing rather than guessing. The policy in [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) allows all of it.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## An address bounced or complained\n\nKestrel acts on these for you, so a bad address can't keep hurting your sending reputation:\n\n- A hard bounce means the address can't receive mail. Kestrel never mails it again.\n- A soft bounce is temporary, such as a full mailbox. The address stays on your list.\n- A complaint means the reader marked your email as spam. Kestrel unsubscribes them, whichever email they reported, and their page, opened from their row, says they left by a complaint.\n\nUnder **Subscribers**, a bounced address keeps its status and carries a label saying why. Its page gives your email provider's words for the bounce and when it happened. When a recent send's bounces reach about 5% of its recipients, the dashboard warns you. That's about the rate at which email providers start to review a sender, so check the addresses on its record.\n\n### Lifting a suppression\n\nLift one only when you know the address works again, such as a reader who tells you their mailbox is fixed. Mailing an address that keeps failing can hurt every send after it. In a subscriber's \u22EF menu, **Unblock** lifts a block and **Clear** lifts a bounce, after asking you to confirm. A complaint isn't a suppression but the reader leaving, so nothing lifts it. They come back only by subscribing again themselves, and **Add subscriber** refuses them. Past records keep the bounce or complaint where it happened.\n\n## An import is refused\n\nNothing on your list changes. Kestrel refuses a file it can't read with certainty, and names the row and column it couldn't. Fix the file and import it again. Convert a file in another format first, with Claude or by hand. Move a column of your old service's into `evidence`. Split a file of more than 10 MB, or with too many rows. [The file format](01-your-list.md#the-file-format) describes what each column takes.\n\n## Claude can't connect\n\n[Connect Claude](08-connect-claude.md) covers connecting it. Most failures are in your instance's Cloudflare Access setup, and [Allow Claude to connect](../guides/01-allow-claude.md#check-it) lists their fixes. When connecting fails:\n\n- **Claude says it couldn't connect, or the sign-in failed.** Check that the connector's address is your publication's address followed by `/api/mcp`, and that your instance is deployed, not running on your own computer. If both are right, your instance's Access setup needs the fix.\n- Signing in shows `invalid_target`, or `kestrel login` says your instance \"doesn't offer a sign-in for programs\". Your instance's Access setup needs the fix.\n- `kestrel login` or `kestrel api` reports a `401`. Access signed you in, but Kestrel refused the sign-in, and your instance's Access setup needs the fix. If either names `access_unidentified`, it's the \"Access let you in\" problem below. If `kestrel api` says your sign-in has ended, sign in again as [Connect Claude](08-connect-claude.md#claude-code) describes.\n- `kestrel api` says it couldn't renew your sign-in because its Access team answered 404 (not found). First check which instance it called: when you don't name one, it prints a line naming it before \"the only instance you're signed in to\", which may not be the one you meant. Name yours with `--url`. If it is yours, the Access team domain was most likely renamed or removed since you signed in. Sign in again with `npx kestrel login` and your instance's address, which finds the team it uses now.\n- **\"Access let you in, but didn't say who you are\".** Your login carried neither an email nor a service token. Sign out, then sign in through the policy that lets you in by email. If you have no such policy, your instance's Access setup needs the fix.\n- **Claude's changes read \"via the API\".** Claude called the API some way other than `kestrel api`, which names Claude Code. Your instance's instructions for Claude Code have it use `kestrel api` once they're brought up to date, as [Install the release](../guides/07-upgrade.md#2-install-the-release) describes. Changes reading \"a service token\" mean Claude still uses one, and [Connect Claude](08-connect-claude.md#claude-code) signs it in as you instead.\n- **A change reads \"via the Kestrel CLI\".** The person it names made it with `kestrel api` outside Claude Code, by hand or through a script, so there's nothing to fix. If Claude Code made it, update Claude Code to v2.1.172 or later: an older one reads this way, and the dashboard can stop saying \"Claude is connected.\"\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## Where to look\n\nWhen a line doesn't settle it, these say the most about what happened:\n\n- The top of the dashboard: what needs someone now, in Kestrel's own words.\n- The send's page, under **Sent**: what happened on that send, when it next retries, and its record of each reader.\n- **Settings \u2192 Email sender**: the state of your Amazon SES account, and your **Send rate**.\n- **Settings \u2192 Notifications**: **Last notification** says whether the last one was delivered, or why not.\n- A subscriber's page, under **Subscribers**: every send they were in, and what happened on each.\n- The app's logs, in your instance's Cloudflare account: [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes them. If someone else set up Kestrel for you, pass this along to them.\n\n## Notifications\n\nWith an address set, Kestrel emails you:\n\n- when a send finishes, with how many emails your provider accepted, and how late it went out if it did\n- when no one's email was accepted for a finished send, since it can't be sent again\n- when email isn't going out and signups are paused: once when it starts, and once more if a post is held after an email that named none\n- when your provider refuses a send or hits a limit, or no provider is connected\n- when the SES sandbox refuses a signup's confirmation, at most once a day\n- when a send stops going out with nothing to explain it, waits for you to resolve it, or doesn't go out on time\n- when your provider has sent no receipts for six hours after a send, once until a receipt arrives\n\nEach says whether anyone has to act, and how. If the fix needs whoever set up your instance, you can forward it as it stands. Each goes to every address set, links to the page it's about, and is sent once while the problem lasts. A reader's address in your provider's words shows only as its domain, and in full on the send's page. If one address can't be reached, the others still get it, and **Last notification** names the one that failed. A bounce spike shows on the dashboard but isn't emailed. **Send a test notification** checks that one arrives.\n\nBy default, notifications go through your newsletter's own email provider. So when that provider refuses your account, the notification about it can't reach you either. You can send them another way, as [Notifications through Cloudflare's email](../guides/03-notifications.md) describes.\n";
+var troubleshooting_default = "# Troubleshooting\n\nWhen something needs you, Kestrel says so in a line on the send's page, under **Sent**. The top of the dashboard shows it too. Red needs you to act, and amber is worth a look. The line says what happened and what to do. This page covers what the screen can't: the fixes made outside Kestrel, and the decisions that are yours.\n\n**Set a notifications address, so a problem reaches you without your watching.** Set it under **Settings \u2192 Notifications**, in **Send notifications to**: type an address and choose **Add inbox**. Add the address of whoever runs your instance too, and both of you are told. With none set, Kestrel emails you nothing. [Notifications](#notifications), below, lists what you're told.\n\n| Symptom | Where the fix is |\n| --- | --- |\n| [A send is held or waiting](#a-send-is-held-or-waiting) | Usually outside Kestrel |\n| [Someone was mailed twice, or not at all](#someone-was-mailed-twice-or-not-at-all) | In Kestrel |\n| [A reader says they never got a post](#a-reader-says-they-never-got-a-post) | In Kestrel |\n| [A send still reads Settling](#a-send-still-reads-settling) | Nothing to fix, unless no receipts come at all |\n| [A test doesn't arrive](#a-test-doesnt-arrive) | Outside Kestrel |\n| [Signups aren't open yet, or are paused](#signups-arent-open-yet-or-are-paused) | In Kestrel, or outside it |\n| [The dashboard names a problem with your Amazon SES account](#a-problem-with-amazon-ses) | Outside Kestrel |\n| [An address bounced or complained](#an-address-bounced-or-complained) | Nothing to fix, unless you lift a suppression |\n| [A warning says to move to Workers Paid](../guides/09-as-your-list-grows.md) | Outside Kestrel |\n| [An import is refused](#an-import-is-refused) | In your file |\n| [Claude can't connect](#claude-cant-connect) | Usually outside Kestrel |\n\n## A send is held or waiting\n\nNothing is lost. A problem with your email provider never marks anyone unsent or mails anyone twice. The send waits where it is, and carries on once the problem is fixed. The send's line names the fix. When that fix is outside Kestrel, it's one of these:\n\n- **Amazon SES refuses your account or the send.** The line carries SES's words and the fix, almost always in the SES console. [Connect Amazon SES](../get-started/05-ses.md) sets up each piece SES checks: the sending domain, the AWS key, and the configuration set. [Request production access](../get-started/06-production-access.md) lifts the sandbox. When SES refuses your account, any other post that comes due meanwhile waits with it. When it refuses only this send's email, other posts go out as usual. While SES takes some readers and refuses the rest, as while a daily quota frees up, those it takes are sent. The line stays until SES takes everyone.\n- **SES keeps refusing for its sending rate.** Kestrel is sending faster than your SES account allows. **Settings \u2192 Email sender** shows the **Send rate** and where it comes from. If `SES_MAX_SEND_RATE` sets it, lower it to the maximum send rate on the SES console's account dashboard, or remove it, then deploy, as [Configuration](../reference/01-configuration.md#vars) describes. If it's Kestrel's default, the app can't read your account: allow its key `ses:GetAccount`, as [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) shows.\n- **No email provider is connected.** Connect one, as [Connect Amazon SES](../get-started/05-ses.md) describes, and the send goes out at its next retry.\n- **A send missed its time, or nothing has gone out for a while.** The part of Kestrel that sends has stopped, or keeps failing on this send. Check the Worker's Cron Trigger, as [Configuration](../reference/01-configuration.md#bindings-and-triggers) describes, and read the app's logs, as [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes. If another send is going out at the same time, this one may only be waiting its turn.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## Someone was mailed twice, or not at all\n\nKestrel never mails a reader twice on its own. When it can't tell whether your provider took some emails, it stops and asks you: the send's page shows **Resolve\u2026**. Choose **Assume not sent** unless you know otherwise, since it's the safe default: those readers may miss this post, but get your next one. Choose **Assume sent** only when you know they got it, such as from a reader who tells you so. Either choice mails no one.\n\nA reader recorded as **Unsent** is still on your list and gets your next post. That send never mails them again: their own email kept failing, SES won't take their address, or you chose **Assume not sent**.\n\n## A reader says they never got a post\n\nUnder **Subscribers**, search for their address and open their row. Their page lists every send they were in, newest first, with what happened on each: **Delivered**, a bounce, a complaint, **Unsent** with your email provider's words, or **Skipped** because they had unsubscribed or were suppressed by then. Each send links to its record. The page also shows how they joined and why they left, if they did. Any bounce or block on the address shows with the provider's words or yours. If they aren't on the list, or are still **pending**, they never confirmed, and only confirmed subscribers are sent your posts.\n\n## A send still reads Settling\n\nThat's normal. **Delivered** counts only the emails your provider confirmed reached the reader's mail server. Confirmations can lag by days, so the counts keep rising after a send finishes. Some are never confirmed at all, so a send can read **Settling** for good, as long as some receipts have come.\n\nWhen none come, the send's page says so an hour after it went out. Your provider's reports aren't reaching Kestrel, so its bounces suppress no one and its complaints unsubscribe no one. Your next post mails those addresses again. Look for `webhook.refused` errors in the app's logs, as [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes. Each names the SNS topic that reached Kestrel and the one it expects. Then check the subscription, as [Connect Amazon SES](../get-started/05-ses.md#7-subscribe-the-app-to-the-topic) describes. If someone else set up Kestrel for you, pass this along to them.\n\n## A test doesn't arrive\n\nWhile Amazon SES is in its sandbox, it mails only addresses verified in SES. Verify the address you test with in the SES console, or [request production access](../get-started/06-production-access.md). When the test's line says the provider didn't answer, check the inbox before you send it again, since the first may have arrived. A test SES refuses for your account has the same fix as [a send it refuses](#a-send-is-held-or-waiting). If someone else set up Kestrel for you, pass this along to them.\n\n## Signups aren't open yet, or are paused\n\nYour subscribe page takes signups only while email is working, so a reader is never told a link is coming when none can go. Every visitor gets the same page, whatever address they enter.\n\n- \"Signups aren\u2019t open yet\" means SES hasn't sent an email for your publication yet. Send one from **Template \u2192 Send test email**, to an address verified in SES while it's in the sandbox. Once SES takes it, signups open. Before an email provider is connected, the page says the same, and [Connect Amazon SES](../get-started/05-ses.md) is the fix.\n- \"Signups are paused\" means SES is refusing your email, every email including confirmations and tests. The dashboard's **Email isn\u2019t going out** line gives SES's words and the fix, as for [a problem with Amazon SES](#a-problem-with-amazon-ses). Then send a test email: once SES takes one, signups reopen.\n\nKestrel notices a refusal when an email meets it, or within about ten minutes from its check of your SES account. A refusal the check found lifts on its own within about ten minutes of the fix; one an email met lifts when a test email goes through. A reader who signed up just as it started may have been told a link was coming, and can sign up again once signups reopen.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## A problem with Amazon SES\n\n**Settings \u2192 Email sender** and the top of the dashboard name a problem with your Amazon SES account within about ten minutes, without sending anything. Red means no email can go out until it's fixed, tests and confirmations included. Amber is worth a look. Each line links the step that fixes it:\n\n- **The configuration set is missing, or its sending is off.** The set Kestrel sends with, the one `SES_CONFIGURATION_SET` names or the sending identity's default if that secret isn't set, isn't in your region, or its sending is turned off. Correct the name, or create the set, as [Connect Amazon SES](../get-started/05-ses.md#4-send-bounces-and-complaints-to-the-app) shows. Turn a set's sending back on in the SES console, under its configuration sets.\n- **SES rejects the AWS key.** The key ID is unknown, the secret doesn't match it, or the AWS account isn't signed up for SES. Store the key's ID and secret again, or create a new key, as [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) shows.\n- **The sender isn't verified.** SES has no verified identity for the From address in your region. Verify the sending hostname, as [Connect Amazon SES](../get-started/05-ses.md#1-verify-your-sending-hostname) shows.\n- **Sending is turned off for the account.** AWS documents turning it back on only with the AWS CLI, naming your region: `aws sesv2 put-account-sending-attributes --sending-enabled --region us-east-1`.\n- **AWS paused the account, or is reviewing it.** AWS does this when the account's bounce or complaint rate runs high. While it reviews, SES still sends, and the line is amber. Once it pauses sending, the line is red. Either way, AWS's email to the AWS account says what it needs: answer it in AWS Support, and check the addresses on your recent sends' records.\n\nThe app needs to read each of these. If its key isn't allowed to, the line says nothing rather than guessing. The policy in [Connect Amazon SES](../get-started/05-ses.md#5-create-the-apps-aws-key) allows all of it.\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## An address bounced or complained\n\nKestrel acts on these for you, so a bad address can't keep hurting your sending reputation:\n\n- A hard bounce means the address can't receive mail. Kestrel never mails it again.\n- A soft bounce is temporary, such as a full mailbox. The address stays on your list.\n- A complaint means the reader marked your email as spam. Kestrel unsubscribes them, whichever email they reported, and their page, opened from their row, says they left by a complaint.\n\nUnder **Subscribers**, a bounced address keeps its status and carries a label saying why. Its page gives your email provider's words for the bounce and when it happened. When a recent send's bounces reach about 5% of its recipients, the dashboard warns you. That's about the rate at which email providers start to review a sender, so check the addresses on its record.\n\n### Lifting a suppression\n\nLift one only when you know the address works again, such as a reader who tells you their mailbox is fixed. Mailing an address that keeps failing can hurt every send after it. In a subscriber's \u22EF menu, **Unblock** lifts a block and **Clear** lifts a bounce, after asking you to confirm. A complaint isn't a suppression but the reader leaving, so nothing lifts it. They come back only by subscribing again themselves, and **Add subscriber** refuses them. Past records keep the bounce or complaint where it happened.\n\n## An import is refused\n\nNothing on your list changes. Kestrel refuses a file it can't read with certainty, and names the row and column it couldn't. Fix the file and import it again. Convert a file in another format first, with Claude or by hand. Move a column of your old service's into `evidence`. Split a file of more than 10 MB, or with too many rows. [The file format](01-your-list.md#the-file-format) describes what each column takes.\n\n## Claude can't connect\n\n[Connect Claude](08-connect-claude.md) covers connecting it. Most failures are in your instance's Cloudflare Access setup, and [Allow Claude to connect](../guides/01-allow-claude.md#check-it) lists their fixes. When connecting fails:\n\n- **Claude says it couldn't connect, or the sign-in failed.** Check that the connector's address is your publication's address followed by `/api/mcp`, and that your instance is deployed, not running on your own computer. If both are right, your instance's Access setup needs the fix.\n- **Claude Code says Dynamic Client Registration was rejected.** `claude mcp login` fails with `Dynamic Client Registration rejected (HTTP 404)`, and a new session shows the connector as failed with the same words. Start `claude`, run `/mcp`, choose the connector, choose Authenticate, and sign in in the browser. The sign-in is stored, so later sessions connect. Nothing on your instance is wrong. `claude mcp login` looks for sign-in details at the standard well-known addresses before reading your instance's own answer, so it never reaches Access. The MCP specification has a client do that only as a fallback.\n- Signing in shows `invalid_target`, or `kestrel login` says your instance \"doesn't offer a sign-in for programs\". Your instance's Access setup needs the fix.\n- `kestrel login` or `kestrel api` reports a `401`. Access signed you in, but Kestrel refused the sign-in, and your instance's Access setup needs the fix. If either names `access_unidentified`, it's the \"Access let you in\" problem below. If `kestrel api` says your sign-in has ended, sign in again as [Connect Claude](08-connect-claude.md#claude-code) describes.\n- `kestrel api` says it couldn't renew your sign-in because its Access team answered 404 (not found). First check which instance it called: when you don't name one, it prints a line naming it before \"the only instance you're signed in to\", which may not be the one you meant. Name yours with `--url`. If it is yours, the Access team domain was most likely renamed or removed since you signed in. Sign in again with `npx kestrel login` and your instance's address, which finds the team it uses now.\n- **\"Access let you in, but didn't say who you are\".** Your login carried neither an email nor a service token. Sign out, then sign in through the policy that lets you in by email. If you have no such policy, your instance's Access setup needs the fix.\n- **Claude's changes read \"via the API\".** Claude called the API some way other than `kestrel api`, which names Claude Code. Your instance's instructions for Claude Code have it use `kestrel api` once they're brought up to date, as [Install the release](../guides/07-upgrade.md#2-install-the-release) describes. Changes reading \"a service token\" mean Claude still uses one, and [Connect Claude](08-connect-claude.md#claude-code) signs it in as you instead.\n- **A change reads \"via the Kestrel CLI\".** The person it names made it with `kestrel api` outside Claude Code, by hand or through a script, so there's nothing to fix. If Claude Code made it, update Claude Code to v2.1.172 or later: an older one reads this way, and the dashboard can stop saying \"Claude is connected.\"\n\nIf someone else set up Kestrel for you, pass this along to them.\n\n## Where to look\n\nWhen a line doesn't settle it, these say the most about what happened:\n\n- The top of the dashboard: what needs someone now, in Kestrel's own words.\n- The send's page, under **Sent**: what happened on that send, when it next retries, and its record of each reader.\n- **Settings \u2192 Email sender**: the state of your Amazon SES account, and your **Send rate**.\n- **Settings \u2192 Notifications**: **Last notification** says whether the last one was delivered, or why not.\n- A subscriber's page, under **Subscribers**: every send they were in, and what happened on each.\n- The app's logs, in your instance's Cloudflare account: [Read the logs](../get-started/07-verify.md#7-read-the-logs) describes them. If someone else set up Kestrel for you, pass this along to them.\n\n## Notifications\n\nWith an address set, Kestrel emails you:\n\n- when a send finishes, with how many emails your provider accepted, and how late it went out if it did\n- when no one's email was accepted for a finished send, since it can't be sent again\n- when email isn't going out and signups are paused: once when it starts, and once more if a post is held after an email that named none\n- when your provider refuses a send or hits a limit, or no provider is connected\n- when the SES sandbox refuses a signup's confirmation, at most once a day\n- when a send stops going out with nothing to explain it, waits for you to resolve it, or doesn't go out on time\n- when your provider has sent no receipts for six hours after a send, once until a receipt arrives\n\nEach says whether anyone has to act, and how. If the fix needs whoever set up your instance, you can forward it as it stands. Each goes to every address set, links to the page it's about, and is sent once while the problem lasts. A reader's address in your provider's words shows only as its domain, and in full on the send's page. If one address can't be reached, the others still get it, and **Last notification** names the one that failed. A bounce spike shows on the dashboard but isn't emailed. **Send a test notification** checks that one arrives.\n\nBy default, notifications go through your newsletter's own email provider. So when that provider refuses your account, the notification about it can't reach you either. You can send them another way, as [Notifications through Cloudflare's email](../guides/03-notifications.md) describes.\n";
 
 // docs/publishing/08-connect-claude.md
 var connect_claude_default = "# Connect Claude\n\nConnecting Claude to Kestrel lets you publish by asking Claude. It drafts, tests, and schedules posts as you, and its changes show as yours, via Claude.\n\n**Your Kestrel instance has to allow this first,** as [Allow Claude to connect](../guides/01-allow-claude.md) describes.\n\nHow you connect depends on where you talk to Claude:\n\n- **In Claude Desktop or claude.ai,** add Kestrel as a connector.\n- **In Claude Code,** add Kestrel as a connector, or sign in with the Kestrel CLI to use the API directly.\n\n## Claude Desktop or claude.ai\n\n1. In Claude, go to **Customize \u2192 Connectors**, select **Add**, then **Add custom connector**.\n1. Name it, and enter your publication's address followed by `/api/mcp`, such as `https://newsletter.example.com/api/mcp`.\n1. Under **OAuth client**, choose **Register automatically**.\n1. Select **Add**, then **Connect**. Sign in the way you do for the dashboard if asked, and choose **Allow**.\n\nOn a Team or Enterprise plan, an Owner of your Claude organization adds the connector under **Organization settings \u2192 Connectors** instead, and you then select **Connect** on it. Anthropic's [custom connectors guide](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) has the details.\n\nTo check it works, ask Claude what your publication is called.\n\n## Claude Code\n\nClaude Code can use the same connector as Claude Desktop and claude.ai. To reach the whole API instead, images included, sign Claude Code in with the Kestrel CLI:\n\n1. Run this, with your publication's address:\n\n    ```bash\n    npx kestrel login https://newsletter.example.com\n    ```\n\n1. Approve the sign-in in the browser that opens. The terminal then says who you're signed in as.\n\nThe sign-in stays on your computer. Opened in your instance's repository, Claude Code then calls Kestrel's API as you through `kestrel api`, the way `gh` calls GitHub, following your instance's instructions for Claude. Its changes show as yours, via Claude Code.\n\n## How long a sign-in lasts\n\nThe sign-in renews itself while you use Claude, until your instance's grant session ends, a week if it follows the setup guide. Then Claude asks you to approve a new one.\n\nTo disconnect, remove the connector under **Customize \u2192 Connectors**. To sign out of the Kestrel CLI, run `npx kestrel logout`.\n\n## Working with Claude\n\nAsk Claude in plain words, the way you'd ask a colleague, and ask it what it can do: it knows its tools, and reads these pages from Kestrel. For example:\n\n- \"Proofread my draft titled 'First frost' and schedule it to go out Friday at 7am.\"\n- \"Add jack@example.com to the list.\"\n- \"Import the subscribers in this CSV from my old newsletter.\"\n\nWhatever Claude is asked, Kestrel holds these for any client:\n\n- **Every send waits out the review window,** and you can cancel it until it goes out.\n- **What goes out is exactly the copy that was scheduled.** A scheduled post is locked.\n- **No one is mailed twice,** and only confirmed subscribers receive a post.\n- **An unsubscribe is final** until the reader subscribes again.\n- **No one's edit is overwritten.** A save based on an older version is refused.\n- **Only you can let an import grow a scheduled send,** in the dashboard.\n\nChanges Claude makes show in the dashboard as yours, such as \"Scheduled by you@example.com via Claude\".\n";
@@ -14097,6 +14177,12 @@ async function uploadImage(c) {
     );
   }
   const dims = probeImageDimensions(new Uint8Array(bytes));
+  if (dims && (dims.width === 0 || dims.height === 0)) {
+    throw badRequest(
+      `This file is a ${FORMAT_NAMES[contentType]}, but its header gives it no size, so it can\u2019t be shown. Export it again, or convert it.`,
+      imageField
+    );
+  }
   let row = null;
   for (let n = 1; !row; n++) {
     const candidate = numberedName(filename, n);
@@ -15134,9 +15220,8 @@ function linkIsLive(row) {
 
 // src/routes/public.ts
 function wantsHtml(c) {
-  const accept = c.req.headers.get("accept") ?? "";
   const ct = c.req.headers.get("content-type") ?? "";
-  return accept.includes("text/html") || ct.includes("application/x-www-form-urlencoded") || ct.includes("multipart/form-data");
+  return asksForHtml(c.req) || ct.includes("application/x-www-form-urlencoded") || ct.includes("multipart/form-data");
 }
 async function readEmail(c) {
   const ct = c.req.headers.get("content-type") ?? "";
@@ -15455,6 +15540,12 @@ var READER_JOURNEYS = [
         label: "Nothing here yet",
         offPath: true,
         at: { base: "archive", path: "/\u2026" }
+      },
+      {
+        id: "no-page",
+        label: "No page here",
+        offPath: true,
+        at: { base: "app", path: "/\u2026" }
       }
     ]
   }
@@ -15895,6 +15986,8 @@ async function previewOf(c, journey, state) {
     }
     case "reading/not-found":
       return nothingHereYetPage(c);
+    case "reading/no-page":
+      return noPageHerePage(c);
   }
   throw notFound("reader page");
 }
@@ -17427,7 +17520,7 @@ function createRouter({
     { name: "limit", description: "Page size (default 50, max 200)." },
     { name: "offset", description: "Rows to skip." }
   ];
-  const r = new Router(isReaderPath);
+  const r = new Router(isReaderPath, noPageHerePage);
   const manifest = [
     // --- system ---
     {
@@ -18130,7 +18223,7 @@ function createRouter({
           name: "file",
           type: "file",
           required: true,
-          description: `The image: a PNG, JPEG, WebP, or GIF, at most ${MAX_POST_IMAGE_BYTES / (1024 * 1024)} MB. Its format is read from its bytes, and a name or declared type that names another of these formats is refused.`
+          description: `The image: a PNG, JPEG, WebP, or GIF, at most ${MAX_POST_IMAGE_BYTES / (1024 * 1024)} MB. Its format is read from its bytes, and a name or declared type that names another of these formats is refused, as is a PNG or WebP whose header states a width or height of zero, or a JPEG whose header states a width of zero.`
         },
         {
           name: "filename",
@@ -19473,11 +19566,10 @@ function createRouter({
     // pages, and the emitted archive URLs always share one source. Self-contained by
     // default; an apex zone can additionally route <base>/* to this Worker (SPEC §11).
     // The index is registered before `:slug` so `/archive` resolves to the list, not
-    // a slug lookup; the optional trailing slash (`{/}?`) means `/archive` and
-    // `/archive/` both land on the index while `/archive/:slug` still serves posts.
+    // a slug lookup.
     {
       method: "GET",
-      path: `${archiveBasePath}{/}?`,
+      path: archiveBasePath,
       access: "public",
       resource: "archive",
       title: "Show the archive",