@kurtbruns/kestrel 1.10.0 → 1.12.0

package/dist/worker/index.js

@@ -1,4 +1,13 @@
-// @kurtbruns/kestrel 1.10.0: the Worker, built by scripts/build-package.mjs.
+// @kurtbruns/kestrel 1.12.0: the Worker, built by scripts/build-package.mjs.
+
+// shared/archive_url.ts
+function archivePostUrl(origin, basePath, slug) {
+  return `${origin}${basePath}/${slug}`;
+}
+var UNLISTED_PATH = "/email";
+function unlistedPostUrl(appOrigin, token2) {
+  return `${appOrigin}${UNLISTED_PATH}/${token2}`;
+}
 
 // shared/daily_writes.ts
 var D1_FREE_DAILY_WRITES = 1e5;
@@ -707,6 +716,13 @@ function describeFormat(maxRows, maxRowsReason) {
 }
 
 // shared/sends.ts
+var SEND_OWN_HALT_CAUSES = ["content", "invalid_request"];
+function isSendOwnHalt(cause) {
+  return cause !== null && SEND_OWN_HALT_CAUSES.includes(cause);
+}
+function haltRank(halt) {
+  return halt.reason === "unavailable" ? 0 : isSendOwnHalt(halt.cause) ? 1 : 2;
+}
 var NOT_CONNECTED_ADVICE = {
   step: "Connect Amazon SES",
   guide: " (the setup guide walks through it)",
@@ -715,20 +731,62 @@ var NOT_CONNECTED_ADVICE = {
 function refusalAdvice(cause) {
   switch (cause) {
     case "credentials":
-      return "Replace the SES access key in the deployment\u2019s secrets, or give it ses:SendEmail and ses:SendBulkEmail in its IAM policy.";
+      return "Whoever runs the deployment replaces the SES access key in its secrets, or gives the key ses:SendEmail and ses:SendBulkEmail in its IAM policy.";
+    case "opt_in":
+      return "The AWS account isn\u2019t signed up for SES: whoever runs the deployment enables SES for the account in the region AWS_REGION names, or settles the account\u2019s activation or billing with AWS.";
     case "configuration":
-      return "Check that the SES_CONFIGURATION_SET secret names a configuration set in your SES region, or create the set in the SES console.";
+      return "Whoever runs the deployment checks that the SES_CONFIGURATION_SET secret names a configuration set in the SES region, or creates the set in the SES console.";
+    case "sending_pool":
+      return "The configuration set SES_CONFIGURATION_SET names sends through a dedicated IP pool SES can\u2019t find: whoever runs the deployment picks an existing pool in the set\u2019s sending options, or removes the pool, in the SES console.";
+    case "unsupported":
+      return "SES read the request as naming something Kestrel never sends, such as a stored template: whoever runs the deployment checks that AWS_REGION names a region that offers SES, and updates Kestrel.";
     case "sender":
-      return "Verify the sending domain or from-address with the provider.";
+      return "Whoever runs the deployment verifies the From address, or its domain, in SES, in the region AWS_REGION names.";
+    case "mail_from":
+      return "SES says the sending domain isn\u2019t verified, or it can\u2019t read the sender\u2019s custom MAIL FROM domain\u2019s MX record: whoever runs the deployment checks that the sending domain is verified in the region AWS_REGION names, and checks the MAIL FROM domain\u2019s MX record in DNS or sets the identity\u2019s Behavior on MX failure to use the default MAIL FROM domain, in the SES console.";
+    case "sandbox":
+      return "The SES account is still in the sandbox, which mails only addresses verified in SES: whoever runs the deployment requests production access on the SES console\u2019s account dashboard. To test before then, verify the reader\u2019s address in SES.";
     case "quota":
-      return "Wait for SES\u2019s 24-hour quota to free up, or ask AWS to raise it in the Service Quotas console.";
+      return "SES\u2019s 24-hour quota frees up on its own. In the sandbox (200 a day), whoever runs the deployment requests production access; otherwise they can ask AWS to raise the quota in the Service Quotas console.";
     case "suspended":
-      return "Settle the account\u2019s standing with the provider (for SES, in the SES console).";
+      return "AWS has shut down the account\u2019s sending, and only AWS can lift it: whoever runs the deployment opens a case with AWS Support from the SES console.";
+    case "paused":
+      return "Sending is paused for the SES account. If AWS paused it under review, its email to the AWS account\u2019s address says what to fix; if it was turned off by hand, whoever runs the deployment turns it back on (aws sesv2 put-account-sending-attributes --sending-enabled).";
+    case "set_paused":
+      return "Sending is turned off on the configuration set SES_CONFIGURATION_SET names, by hand or by an alarm set up on it: whoever runs the deployment turns it back on (aws sesv2 put-configuration-set-sending-options --sending-enabled, naming the set).";
+    case "content":
+      return "SES refuses this email itself, not a reader or the account, and the email can\u2019t change once its send has started: whoever runs the deployment asks AWS Support what SES refuses in it, quoting SES\u2019s words.";
+    case "invalid_request":
+      return "SES refused a batch of this send as invalid. If its words name an address, remove that subscriber: the send skips anyone no longer on the list, and resumes at its next retry.";
     case "not_connected":
       return `${NOT_CONNECTED_ADVICE.step}${NOT_CONNECTED_ADVICE.guide}${NOT_CONNECTED_ADVICE.after}`;
     default:
-      return "Fix the account with the provider.";
+      return "Whoever runs the deployment fixes the account with the provider.";
+  }
+}
+var SELF_THROTTLE_HALTS = 3;
+function isSelfThrottled(send) {
+  return send.halt_reason === "unavailable" && send.halt_cause === "rate_limit" && send.halt_retries >= SELF_THROTTLE_HALTS;
+}
+function sentence(error) {
+  const text = error?.trim() || "no detail given";
+  return /[.!?]$/.test(text) ? text : `${text}.`;
+}
+function refusedMessage(cause, error) {
+  const advice = refusalAdvice(cause);
+  if (cause === "not_connected") {
+    return `No email provider is connected, so this send is held where it is. ${advice} No one has been marked unsent because of this, and the send goes out at its first retry after a provider is connected.`;
+  }
+  if (isSendOwnHalt(cause)) {
+    return `The provider is refusing this send: ${sentence(error)} ${advice} No one has been marked unsent because of this, and the send tries again on its own, spaced out the longer this lasts.`;
   }
+  return `The provider is refusing the account: ${sentence(error)} ${advice} No one has been marked unsent because of this, and the send resumes on its own at its next retry once the account is fixed.`;
+}
+function unavailableMessage(send) {
+  if (isSelfThrottled(send)) {
+    return `The provider keeps refusing for its sending rate: ${sentence(send.halt_error)} A burst clears within a second, and this has refused the first request of ${send.halt_retries} retries in a row, minutes apart, so the deployment is asking for more a second than the account allows. Whoever runs the deployment sets SES_MAX_SEND_RATE to the maximum send rate on the SES console\u2019s account dashboard (1 a second in the sandbox), and deploys. The send retries on its own meanwhile, and no one has been marked unsent because of this.`;
+  }
+  return `The provider is unavailable: ${sentence(send.halt_error)} The send retries on its own, spaced out the longer this lasts, and no one has been marked unsent because of this.`;
 }
 var STUCK_THRESHOLD_MS = 30 * 60 * 1e3;
 var DEFAULT_MIN_LEAD_MS = 5 * 60 * 1e3;
@@ -748,6 +806,7 @@ function tooSoonMessage(minLeadMs) {
 var BOUNCE_SPIKE_RATE = 0.05;
 var BOUNCE_SPIKE_MIN = 3;
 var BOUNCE_SPIKE_RECENT_MS = 7 * 24 * 60 * 60 * 1e3;
+var NO_RECEIPTS_AFTER_MS = 60 * 60 * 1e3;
 var DAILY_WRITES_SEND_RECIPIENTS = Math.floor(
   DAILY_WRITES_BUDGET / SEND_WRITES_PER_RECIPIENT
 );
@@ -808,10 +867,10 @@ var SUBSCRIBER_ACTIONS = {
 
 // src/generated/version.ts
 var BUILD_INFO = {
-  version: "1.10.0",
-  sha: "ea8b761",
-  tag: "v1.10.0",
-  buildTime: "2026-10-14T22:23:51.195Z",
+  version: "1.12.0",
+  sha: "27e2c43",
+  tag: "v1.12.0",
+  buildTime: "2026-10-16T18:01:02.170Z",
   repoUrl: "https://github.com/kurtbruns/kestrel"
 };
 
@@ -835,6 +894,17 @@ function buildInfo() {
 
 // src/lib/log.ts
 import { AsyncLocalStorage } from "node:async_hooks";
+
+// src/lib/redact.ts
+var CREDENTIAL = /(Credential=)[^,\s&"']+/gi;
+var SIGNATURE = /(Signature=)[0-9a-f]+/gi;
+var SECURITY_TOKEN = /(x-amz-security-token[:=]\s*)[^\s&,"']+/gi;
+var ACCESS_KEY_ID = /\b(?:AKIA|ASIA)[0-9A-Z]{16}\b/g;
+function redactCredentials(text) {
+  return text.replace(CREDENTIAL, "$1\u2026").replace(SIGNATURE, "$1\u2026").replace(SECURITY_TOKEN, "$1\u2026").replace(ACCESS_KEY_ID, "\u2026");
+}
+
+// src/lib/log.ts
 var runs = new AsyncLocalStorage();
 function withRun(run, fn) {
   return runs.run(run, fn);
@@ -845,7 +915,7 @@ function newRun() {
 var ADDRESS = /(?:"[^"\r\n]*"|[^\s<>"'(),;:@/?&=[\]]+?)(?:@|%40)(\[[^\]\s]*\]|[\p{L}\p{N}_-]+(?:\.[\p{L}\p{N}_-]+)*)/giu;
 var TOKEN = /([?&;]token=)[^&\s"'#<>]+/gi;
 function scrub(text) {
-  return text.replace(ADDRESS, "\u2026@$1").replace(TOKEN, "$1\u2026");
+  return redactCredentials(text).replace(ADDRESS, "\u2026@$1").replace(TOKEN, "$1\u2026");
 }
 function emit(level, event, fields) {
   try {
@@ -1017,7 +1087,7 @@ ${JSON.stringify(value, null, 2)}
 \`\`\``;
 }
 function routeMarkdown(r) {
-  const parts = [`### ${r.method} ${r.path}`, r.summary];
+  const parts = [`#### ${r.method} ${r.path}`, r.summary];
   if (r.description) {
     parts.push(r.description);
   }
@@ -1045,7 +1115,7 @@ Every route this instance serves, generated from its registration, so every endp
   const tiers = groups.map((g) => {
     const resources = g.resources.map(
       (res) => [
-        `## ${g.title}: ${res.title}`,
+        `### ${res.title}`,
         ...g.routes.filter((r) => r.resource === res.key).map(routeMarkdown)
       ].join("\n\n")
     );
@@ -1083,26 +1153,34 @@ async function verifyAccessJwt(token2, config) {
       issuer,
       audience: config.accessAud
     });
-    const email2 = typeof payload.email === "string" ? payload.email : void 0;
-    if (email2) {
-      if (!isHumanAllowed(email2, config.accessAllowedEmails)) {
-        return null;
-      }
-      return { kind: "human", email: email2, via: "access" };
-    }
-    return { kind: "service", via: "access" };
+    return principalFromClaims(payload, config.accessAllowedEmails);
   } catch {
     return null;
   }
 }
+function principalFromClaims(payload, allowed) {
+  const email2 = typeof payload.email === "string" ? payload.email : void 0;
+  if (email2) {
+    return isHumanAllowed(email2, allowed) ? { kind: "human", email: email2, via: "access" } : null;
+  }
+  const claims = Object.keys(payload).sort().join(",");
+  const tokenId = typeof payload.common_name === "string" ? payload.common_name : void 0;
+  if (tokenId) {
+    log.info("auth.service", { claims });
+    return { kind: "service", tokenId, via: "access" };
+  }
+  log.warn("auth.unidentified", { claims });
+  return { kind: "service", via: "access" };
+}
 
 // src/auth/dev_token.ts
 import { jwtVerify as jwtVerify2, SignJWT } from "jose";
 var DEV_ISSUER = "kestrel-dev";
 var DEV_AUDIENCE = "kestrel-admin";
+var DEV_TOKEN_ID = "kestrel-dev.access";
 var keyFor = (secret) => new TextEncoder().encode(secret);
 async function mintDevToken(secret, claims = {}, ttl = "12h") {
-  return new SignJWT(claims.email ? { email: claims.email } : {}).setProtectedHeader({ alg: "HS256" }).setIssuer(DEV_ISSUER).setAudience(DEV_AUDIENCE).setIssuedAt().setExpirationTime(ttl).sign(keyFor(secret));
+  return new SignJWT(claims.email ? { email: claims.email } : { common_name: DEV_TOKEN_ID }).setProtectedHeader({ alg: "HS256" }).setIssuer(DEV_ISSUER).setAudience(DEV_AUDIENCE).setIssuedAt().setExpirationTime(ttl).sign(keyFor(secret));
 }
 async function verifyDevToken(token2, secret) {
   try {
@@ -1111,7 +1189,11 @@ async function verifyDevToken(token2, secret) {
       audience: DEV_AUDIENCE
     });
     const email2 = typeof payload.email === "string" ? payload.email : void 0;
-    return email2 ? { kind: "human", email: email2, via: "dev" } : { kind: "service", via: "dev" };
+    if (email2) {
+      return { kind: "human", email: email2, via: "dev" };
+    }
+    const tokenId = typeof payload.common_name === "string" ? payload.common_name : void 0;
+    return { kind: "service", via: "dev", ...tokenId ? { tokenId } : {} };
   } catch {
     return null;
   }
@@ -1330,10 +1412,10 @@ function refusePlaceholders(provider, env, origins) {
   if (fromDomain) {
     hosts.push(["FROM_ADDRESS", fromDomain]);
   }
-  const why = provider === "none" ? "replace it with your own domain" : `PROVIDER "${provider}" sends real email`;
+  const why2 = provider === "none" ? "replace it with your own domain" : `PROVIDER "${provider}" sends real email`;
   for (const [name, host] of hosts) {
     if (isPlaceholderHost(host)) {
-      throw new ConfigError(name, `is still on the template's example.com placeholder; ${why}`);
+      throw new ConfigError(name, `is still on the template's example.com placeholder; ${why2}`);
     }
   }
 }
@@ -1864,8 +1946,12 @@ function isForeignBrowserRequest(c) {
   const origin = c.req.headers.get("origin");
   return origin !== null && origin !== c.url.origin;
 }
+async function isEmptyBody(req) {
+  const bytes = await req.clone().arrayBuffer();
+  return new TextDecoder().decode(bytes).trim() === "";
+}
 function refuseForeignWrite(accepts) {
-  return (c) => {
+  return async (c) => {
     if (isForeignBrowserRequest(c)) {
       throw new HttpError(
         403,
@@ -1875,6 +1961,9 @@ function refuseForeignWrite(accepts) {
     }
     const type = mediaTypeOf(c.req);
     if (type !== void 0 && !accepts.includes(type)) {
+      if (accepts.length === 0 && type === "application/json" && await isEmptyBody(c.req)) {
+        return void 0;
+      }
       throw unsupportedMediaType(
         accepts.length === 0 ? `this route takes no body, so no Content-Type (got ${type})` : `this route accepts ${accepts.join(" or ")}, not ${type}`
       );
@@ -1973,6 +2062,9 @@ function newToken(bytes = 32) {
   }
   return out;
 }
+function newUnlistedToken() {
+  return newToken(16).replace(/(.{8})(?=.)/g, "$1-");
+}
 function newTokens(n, bytes = 32) {
   const buf = new Uint8Array(n * bytes);
   for (let at = 0; at < buf.length; at += 65536) {
@@ -2070,6 +2162,9 @@ function tombstoneSendsStmt(db, where, ...binds) {
     `INSERT OR REPLACE INTO send_tombstones (id, rev) SELECT id, ${NEXT_REV} FROM sends WHERE ${where}`
   ).bind(...binds);
 }
+function stampSendsOfPostStmt(db, postId) {
+  return db.prepare(`UPDATE sends SET rev = ${NEXT_REV} WHERE post_id = ?`).bind(postId);
+}
 function bucketCol(status, event) {
   if (event === "delivered") {
     return "c_delivered";
@@ -2134,11 +2229,25 @@ function publishedSendForPost(db, postId) {
     `SELECT * FROM sends s WHERE s.post_id = ? AND ${PUBLISHED_SEND} ORDER BY ${PUBLISHED_AT} DESC LIMIT 1`
   ).bind(postId).first();
 }
+async function publicationsFor(db, postIds) {
+  if (postIds.length === 0) {
+    return /* @__PURE__ */ new Map();
+  }
+  const { results } = await db.prepare(
+    `SELECT s.post_id AS post_id, MAX(${PUBLISHED_AT}) AS published_at, s.web_link AS web_link
+         FROM sends s
+        WHERE s.post_id IN (SELECT value FROM json_each(?)) AND ${PUBLISHED_SEND}
+        GROUP BY s.post_id`
+  ).bind(JSON.stringify(postIds)).all();
+  return new Map(
+    results.map((r) => [r.post_id, { published_at: r.published_at, web_link: r.web_link }])
+  );
+}
 async function listPublishedPosts(db, limit = 200) {
   const { results } = await db.prepare(
     `SELECT p.slug AS slug, s.subject AS subject, MAX(${PUBLISHED_AT}) AS published_at
          FROM sends s JOIN posts p ON p.id = s.post_id
-         WHERE ${PUBLISHED_SEND}
+         WHERE ${PUBLISHED_SEND} AND p.email_only = 0
          GROUP BY s.post_id
          ORDER BY published_at DESC
          LIMIT ?`
@@ -2155,8 +2264,15 @@ var SEND_LIST_SPEC = {
   defaultSort: "fire",
   defaultDir: "desc"
 };
-var SEND_LIST_COLS = "id, post_id, status, fire_at, subject, recipient_count, locked_until, scheduled_at, started_at, completed_at, audience_resolved_at, remade_at, tested_at, halt_reason, halt_cause, halt_error, halted_at, halt_retries, halt_retry_at, c_pending, c_in_flight, c_accepted, c_delivered, c_bounced, c_complained, c_skipped, c_unsent, rev";
-var VIEW_COLS = `${SEND_LIST_COLS}, (SELECT p.slug FROM posts p WHERE p.id = sends.post_id) AS post_slug`;
+var SEND_LIST_COLS = "id, post_id, status, fire_at, subject, recipient_count, locked_until, scheduled_at, started_at, completed_at, audience_resolved_at, remade_at, tested_at, halt_reason, halt_cause, halt_error, halted_at, halt_retries, halt_retry_at, progress_at, c_pending, c_in_flight, c_accepted, c_delivered, c_bounced, c_complained, c_skipped, c_unsent, rev";
+var postCol = (col, as) => `(SELECT p.${col} FROM posts p WHERE p.id = sends.post_id) AS ${as}`;
+var VIEW_COLS = [
+  SEND_LIST_COLS,
+  "web_link",
+  postCol("slug", "post_slug"),
+  postCol("unlisted_token", "post_unlisted_token"),
+  postCol("email_only", "post_email_only")
+].join(", ");
 async function getSendViewRow(db, id) {
   return db.prepare(
     `SELECT ${VIEW_COLS},
@@ -2202,6 +2318,11 @@ async function currentSendSeq(db) {
   const row = await db.prepare(`SELECT ${CURRENT_REV} AS seq`).first();
   return unwrap(row?.seq, "the send sequence");
 }
+var WEDGED_SEND = "(status = 'sending' AND c_pending = 0 AND c_in_flight > 0 AND locked_until IS NULL)";
+var SEND_IDLE_SINCE = "MAX(COALESCE(progress_at, started_at), COALESCE(halt_retry_at, 0))";
+function stuckSendSql(cutoff) {
+  return `(status = 'sending' AND started_at IS NOT NULL AND NOT ${WEDGED_SEND} AND ${SEND_IDLE_SINCE} < ${cutoff})`;
+}
 var LIVE_SEND = "(status = 'scheduled' AND fire_at <= ?1) OR status = 'sending' OR (status = 'sent' AND c_accepted > 0 AND completed_at >= ?2)";
 var CHANGES = `SELECT rev FROM sends WHERE rev > ?2
   UNION ALL SELECT rev FROM send_tombstones WHERE rev > ?2`;
@@ -2211,7 +2332,10 @@ var CHANGED_SINCE = `(${IN_PAGE})
   OR (status = 'scheduled' AND (
        (fire_at > ?3 AND fire_at <= ?1)
     OR (fire_at + ?4 >= ?3 AND fire_at + ?4 < ?1)))
-  OR (status = 'sending' AND started_at + ?5 >= ?3 AND started_at + ?5 < ?1)`;
+  OR (status = 'sending' AND started_at IS NOT NULL AND NOT ${WEDGED_SEND}
+      AND ${SEND_IDLE_SINCE} + ?5 >= ?3 AND ${SEND_IDLE_SINCE} + ?5 < ?1)
+  OR (status = 'sent' AND c_accepted > 0 AND c_delivered + c_bounced + c_complained = 0
+      AND completed_at + ?7 >= ?3 AND completed_at + ?7 < ?1)`;
 async function sendFeed(db, now, since, settledSince, thresholds, limit, recentSince) {
   const select = `SELECT ${VIEW_COLS},
          CASE WHEN status = 'sending' THEN ${activeRetriesSql("sends.id")} ELSE 0 END AS has_retries
@@ -2225,7 +2349,15 @@ async function sendFeed(db, now, since, settledSince, thresholds, limit, recentS
     db.prepare(
       "SELECT MAX(completed_at) AS at FROM sends WHERE status = 'sent' AND c_accepted > 0"
     ),
-    since ? db.prepare(`${select} WHERE ${CHANGED_SINCE} ORDER BY fire_at ASC, id ASC`).bind(now, since.seq, since.at, thresholds.missedMs, thresholds.stuckMs, limit) : db.prepare(`${select} WHERE ${LIVE_SEND} ORDER BY fire_at ASC, id ASC`).bind(now, settledSince)
+    since ? db.prepare(`${select} WHERE ${CHANGED_SINCE} ORDER BY fire_at ASC, id ASC`).bind(
+      now,
+      since.seq,
+      since.at,
+      thresholds.missedMs,
+      thresholds.stuckMs,
+      limit,
+      thresholds.noReceiptsMs
+    ) : db.prepare(`${select} WHERE ${LIVE_SEND} ORDER BY fire_at ASC, id ASC`).bind(now, settledSince)
   ];
   if (since) {
     statements.push(
@@ -2354,6 +2486,9 @@ async function countDeliveriesFiltered(db, sendId, view, search) {
   const row = await db.prepare(`SELECT COUNT(*) AS n FROM deliveries d ${clause}`).bind(...binds).first();
   return row?.n ?? 0;
 }
+function renderWarnings(send) {
+  return JSON.parse(send.render_warnings);
+}
 function settingsVersionIs(version) {
   return {
     sql: "COALESCE((SELECT updated_at FROM settings WHERE id = 1), 0) = ?",
@@ -2363,8 +2498,8 @@ function settingsVersionIs(version) {
 function insertScheduledSendStmt(db, send, now, settingsVersion) {
   const guard2 = settingsVersionIs(settingsVersion);
   return db.prepare(
-    `INSERT INTO sends (id, post_id, status, fire_at, rendered_html, rendered_text, subject, recipient_count, scheduled_at, rev)
-       SELECT ?, ?, 'scheduled', ?, ?, ?, ?, ?, ?, ${NEXT_REV}
+    `INSERT INTO sends (id, post_id, status, fire_at, rendered_html, rendered_text, subject, render_warnings, recipient_count, scheduled_at, web_link, rev)
+       SELECT ?, ?, 'scheduled', ?, ?, ?, ?, ?, ?, ?, 'unlisted', ${NEXT_REV}
         WHERE ${guard2.sql}`
   ).bind(
     send.id,
@@ -2373,6 +2508,7 @@ function insertScheduledSendStmt(db, send, now, settingsVersion) {
     send.rendered_html,
     send.rendered_text,
     send.subject,
+    JSON.stringify(send.warnings),
     send.recipient_count,
     now,
     ...guard2.binds
@@ -2419,15 +2555,22 @@ function remakeGuard(settingsVersion, minFireAt, ackIds) {
 }
 function remakeSendStmt(db, sendId, render2, now, guard2) {
   return db.prepare(
-    `UPDATE sends SET rendered_html = ?, rendered_text = ?, subject = ?, remade_at = ?, rev = ${NEXT_REV}
+    `UPDATE sends SET rendered_html = ?, rendered_text = ?, subject = ?, render_warnings = ?, remade_at = ?, web_link = 'unlisted', rev = ${NEXT_REV}
         WHERE id = ? AND status = 'scheduled' AND ${guard2.sql}`
-  ).bind(render2.rendered_html, render2.rendered_text, render2.subject, now, sendId, ...guard2.binds);
+  ).bind(
+    render2.rendered_html,
+    render2.rendered_text,
+    render2.subject,
+    JSON.stringify(render2.warnings),
+    now,
+    sendId,
+    ...guard2.binds
+  );
 }
 async function dueSends(db, now) {
   const { results } = await db.prepare("SELECT * FROM sends WHERE status = 'scheduled' AND fire_at <= ? ORDER BY fire_at ASC").bind(now).all();
   return results;
 }
-var WEDGED_SEND = "(status = 'sending' AND c_pending = 0 AND c_in_flight > 0 AND locked_until IS NULL)";
 async function resumableSends(db, now, retryDueBy) {
   const { results } = await db.prepare(
     `SELECT * FROM sends WHERE status = 'sending' AND (locked_until IS NULL OR locked_until < ?)
@@ -2436,14 +2579,50 @@ async function resumableSends(db, now, retryDueBy) {
   ).bind(now, retryDueBy).all();
   return results;
 }
+async function accountHalt(db, sendId, aheadOf) {
+  const row = await db.prepare(
+    `SELECT id, halt_reason, halt_cause, halt_error, halted_at, halt_retries, halt_retry_at
+         FROM sends
+        WHERE status = 'sending' AND id <> ? AND halt_reason IS NOT NULL
+          AND halt_retry_at > ? AND NOT ${WEDGED_SEND}
+          AND (halt_cause IS NULL OR halt_cause NOT IN (SELECT value FROM json_each(?)))
+        ORDER BY halt_reason = 'account' DESC, halt_retry_at DESC
+        LIMIT 1`
+  ).bind(sendId, aheadOf, JSON.stringify(SEND_OWN_HALT_CAUSES)).first();
+  return row ? {
+    sendId: row.id,
+    reason: row.halt_reason,
+    cause: row.halt_cause,
+    error: row.halt_error ?? "",
+    since: row.halted_at ?? row.halt_retry_at,
+    retries: row.halt_retries,
+    retryAt: row.halt_retry_at
+  } : null;
+}
+async function joinHalt(db, sendId, lease, halt) {
+  await db.prepare(
+    `UPDATE sends SET halt_reason = ?, halt_cause = ?, halt_error = ?,
+              halted_at = CASE WHEN halt_reason IS ? AND halted_at IS NOT NULL THEN halted_at ELSE ? END,
+              halt_retries = ?, halt_retry_at = ?, rev = ${NEXT_REV}
+        WHERE id = ? AND lease_token = ?`
+  ).bind(
+    halt.reason,
+    halt.cause,
+    halt.error,
+    halt.reason,
+    halt.since,
+    halt.retries,
+    halt.retryAt,
+    sendId,
+    lease
+  ).run();
+}
 async function wedgedSends(db) {
   const { results } = await db.prepare(`SELECT * FROM sends WHERE ${WEDGED_SEND} ORDER BY started_at ASC`).all();
   return results;
 }
-async function stuckSends(db, olderThan) {
-  const { results } = await db.prepare(
-    "SELECT * FROM sends WHERE status = 'sending' AND started_at IS NOT NULL AND started_at < ?"
-  ).bind(olderThan).all();
+async function stuckSends(db, idleBefore) {
+  const { results } = await db.prepare(`SELECT * FROM sends WHERE ${stuckSendSql("?")} ORDER BY started_at ASC`).bind(idleBefore).all();
   return results;
 }
 async function acquireLease(db, sendId, now, leaseTtlMs) {
@@ -2627,7 +2806,7 @@ var OUTCOME_BUCKET = {
   skipped: "c_skipped",
   pending: "c_pending"
 };
-async function settleDeliveries(db, sendId, lease, from, outcomes, now, answered = false) {
+async function settleDeliveries(db, sendId, lease, from, outcomes, now, answer = { progressed: false, clears: false }) {
   if (outcomes.length === 0) {
     return;
   }
@@ -2649,7 +2828,12 @@ async function settleDeliveries(db, sendId, lease, from, outcomes, now, answered
   }
   const cols = [...deltas.keys()];
   const sets = cols.map((c) => `${c} = ${c} + ?`);
-  if (answered) {
+  const values = cols.map((c) => deltas.get(c) ?? 0);
+  if (answer.progressed) {
+    sets.push("progress_at = ?");
+    values.push(now);
+  }
+  if (answer.clears) {
     sets.push(
       "halt_reason = NULL",
       "halt_cause = NULL",
@@ -2678,7 +2862,7 @@ async function settleDeliveries(db, sendId, lease, from, outcomes, now, answered
     // The column names come from the fixed `CounterCol` union, never user input.
     db.prepare(
       `UPDATE sends SET ${sets.join(", ")}, rev = ${NEXT_REV} WHERE id = ? AND lease_token = ?`
-    ).bind(...cols.map((c) => deltas.get(c) ?? 0), sendId, lease)
+    ).bind(...values, sendId, lease)
   ]);
 }
 async function openDeliveryCount(db, sendId) {
@@ -2800,12 +2984,117 @@ async function acceptedAwaitingEvent(db, limit) {
 
 // src/db/posts.ts
 function fromStored(row) {
-  return { ...row, slug_auto: row.slug_auto === 1 };
+  return {
+    ...row,
+    slug_auto: row.slug_auto === 1,
+    email_only: row.email_only === 1
+  };
 }
 function setPostStatusStmt(db, postId, from, to, now, guard2) {
   const extra = guard2 ? ` AND ${guard2.sql}` : "";
   return db.prepare(`UPDATE posts SET status = ?, updated_at = ? WHERE id = ? AND status = ?${extra}`).bind(to, now, postId, from, ...guard2?.binds ?? []);
 }
+function slugOf(text) {
+  return slugify(text) || EMPTY_SUBJECT_SLUG;
+}
+var SLUG_MAX = 80;
+function slugWellFormed(slug) {
+  return slug.length <= SLUG_MAX && /^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(slug);
+}
+var SlugRefused = class extends Error {
+  constructor(code) {
+    super(code);
+    this.code = code;
+    this.name = "SlugRefused";
+  }
+  code;
+};
+async function resolveSlug(db, current2, change) {
+  const auto = change.slugAuto ?? (change.slug === void 0 && current2.slugAuto);
+  if (!auto && change.slug === void 0 && current2.slug === void 0) {
+    return { slug: await uniqueSlug(db, slugOf(current2.subject), current2.postId), auto: false };
+  }
+  if (!auto) {
+    const slug = change.slug ?? current2.slug ?? slugOf(current2.subject);
+    if (change.slug !== void 0) {
+      if (!slugWellFormed(slug)) {
+        return { refused: "slug_invalid" };
+      }
+      if (await slugTaken(db, slug, current2.postId)) {
+        return { refused: "slug_taken" };
+      }
+    }
+    return { slug, auto: false };
+  }
+  const wanted = slugOf(current2.subject);
+  if (!await slugTaken(db, wanted, current2.postId)) {
+    return { slug: wanted, auto: true };
+  }
+  if (current2.slug && isNumberOf(current2.slug, wanted)) {
+    return { slug: current2.slug, auto: true };
+  }
+  return { slug: await uniqueSlug(db, wanted, current2.postId), auto: true };
+}
+function isNumberOf(slug, base) {
+  return slug.startsWith(`${base}-`) && /^[1-9][0-9]*$/.test(slug.slice(base.length + 1));
+}
+async function subjectSlugHeld(db, post) {
+  const wanted = slugify(post.subject);
+  if (!post.slug_auto || !wanted || wanted === post.slug) {
+    return null;
+  }
+  if (!await slugTaken(db, wanted, post.id)) {
+    return null;
+  }
+  return await publishedSendForPost(db, post.id) ? null : wanted;
+}
+function isSlugCollision(err) {
+  return /UNIQUE constraint failed:\s*posts\.slug/i.test(
+    err instanceof Error ? err.message : String(err)
+  );
+}
+function setPublishingStmt(db, post, input, guard2) {
+  const sets = [];
+  const binds = [];
+  if (input.emailOnly !== void 0) {
+    sets.push("email_only = ?");
+    binds.push(input.emailOnly ? 1 : 0);
+  }
+  const where = ["id = ?"];
+  if (slugMoves(post, input)) {
+    const slug = unwrap(input.slug, "slug");
+    sets.push("slug = ?", "slug_auto = ?");
+    binds.push(slug.slug, slug.auto ? 1 : 0);
+    where.push(
+      "NOT EXISTS (SELECT 1 FROM sends WHERE sends.post_id = posts.id AND sends.status IN ('sending', 'sent'))"
+    );
+  }
+  if (guard2) {
+    where.push(guard2.sql);
+  }
+  return db.prepare(
+    `UPDATE posts SET ${sets.length ? sets.join(", ") : "id = id"} WHERE ${where.join(" AND ")}`
+  ).bind(...binds, post.id, ...guard2?.binds ?? []);
+}
+function slugMoves(post, input) {
+  return input.slug !== void 0 && (input.slug.slug !== post.slug || input.slug.auto !== post.slug_auto);
+}
+function publishingChanges(post, input) {
+  return input.emailOnly !== void 0 && input.emailOnly !== post.email_only || slugMoves(post, input);
+}
+async function setPublishing(db, post, input) {
+  if (!publishingChanges(post, input)) {
+    return "unchanged";
+  }
+  const [written] = await db.batch([
+    setPublishingStmt(db, post, input),
+    stampSendsOfPostStmt(db, post.id)
+  ]);
+  if (unwrap(written, "settings write").meta.changes > 0) {
+    return "changed";
+  }
+  return await getPost(db, post.id) ? "address_fixed" : "missing";
+}
 async function getPost(db, id) {
   const row = await db.prepare("SELECT * FROM posts WHERE id = ?").bind(id).first();
   return row && fromStored(row);
@@ -2814,6 +3103,10 @@ async function getBySlug(db, slug) {
   const row = await db.prepare("SELECT * FROM posts WHERE slug = ?").bind(slug).first();
   return row && fromStored(row);
 }
+async function getByUnlistedToken(db, token2) {
+  const row = await db.prepare("SELECT * FROM posts WHERE unlisted_token = ?").bind(token2).first();
+  return row && fromStored(row);
+}
 var POST_LIST_SPEC = {
   columns: {
     updated: "p.updated_at",
@@ -2901,8 +3194,15 @@ async function createPost(db, input, author2) {
   const revId = newId();
   const subject = input.subject ?? "";
   const markdown2 = input.markdown ?? "";
-  const auto = input.slug_auto ?? input.slug === void 0;
-  const slug = await uniqueSlug(db, slugify(auto ? subject : input.slug ?? subject));
+  const resolved = await resolveSlug(
+    db,
+    { slugAuto: input.slug === void 0, subject },
+    { slug: input.slug, slugAuto: input.slug_auto }
+  );
+  if ("refused" in resolved) {
+    throw new SlugRefused(resolved.refused);
+  }
+  const { slug, auto } = resolved;
   const metadata = JSON.stringify({ subject, slug });
   await db.batch([
     db.prepare(
@@ -2925,13 +3225,15 @@ async function updatePost(db, post, input, author2) {
   const revId = newId();
   const subject = input.subject ?? post.subject;
   const markdown2 = input.markdown ?? current2?.markdown ?? "";
-  const auto = input.slug_auto ?? (input.slug === void 0 && post.slug_auto);
-  let slug = post.slug;
-  if (auto) {
-    slug = await uniqueSlug(db, slugify(subject), post.id);
-  } else if (input.slug !== void 0) {
-    slug = await uniqueSlug(db, slugify(input.slug), post.id);
+  const resolved = await resolveSlug(
+    db,
+    { postId: post.id, slug: post.slug, slugAuto: post.slug_auto, subject },
+    { slug: input.slug, slugAuto: input.slug_auto }
+  );
+  if ("refused" in resolved) {
+    throw new SlugRefused(resolved.refused);
   }
+  const { slug, auto } = resolved;
   const metadata = JSON.stringify({ subject, slug });
   await db.batch([
     db.prepare(
@@ -2962,9 +3264,18 @@ async function deletePost(db, id) {
   ]);
 }
 
-// shared/archive_url.ts
-function archivePostUrl(origin, basePath, slug) {
-  return `${origin}${basePath}/${slug}`;
+// src/lib/archive_address.ts
+function withAddresses(config, post, publication) {
+  return {
+    ...post,
+    archive_url: archivePostUrl(config.archiveOrigin, config.archiveBasePath, post.slug),
+    unlisted_url: unlistedPostUrl(config.appOrigin, post.unlisted_token),
+    published_at: publication?.published_at ?? null,
+    archive_live: publication !== null && archiveAnswers({ emailOnly: post.email_only, webLink: publication.web_link })
+  };
+}
+function archiveAnswers(post) {
+  return !post.emailOnly || post.webLink === "archive";
 }
 
 // shared/email_logo.ts
@@ -3780,9 +4091,9 @@ var EMAIL_MAX_WIDTH = 600;
 function readMeta(revision, post) {
   try {
     const m = JSON.parse(revision.metadata);
-    return { subject: m.subject ?? post.subject, slug: m.slug ?? post.slug };
+    return { subject: m.subject ?? post.subject };
   } catch {
-    return { subject: post.subject, slug: post.slug };
+    return { subject: post.subject };
   }
 }
 function derivePreheader(bodyText) {
@@ -3809,7 +4120,7 @@ async function render(input, config, branding = defaultBranding()) {
     );
   }
   const subject = hasSubject ? meta.subject : "(no subject)";
-  const viewInBrowserUrl = archiveUrl(config, meta.slug);
+  const viewInBrowserUrl = unlistedPostUrl(config.appOrigin, input.post.unlisted_token);
   const validation = validateEmailTemplate(branding.template);
   let template = branding.template;
   if (validation.errors.length > 0) {
@@ -3957,13 +4268,7 @@ function nothingHereYetPage(c) {
     status: 404
   });
 }
-async function archivePage(c) {
-  const slug = param(c, "slug");
-  const post = await getBySlug(c.env.DB, slug);
-  const send = post ? await publishedSendForPost(c.env.DB, post.id) : null;
-  if (!post || !send) {
-    return nothingHereYetPage(c);
-  }
+async function postPage(c, post, send) {
   const html = webVersion(send.rendered_html, {
     config: c.config,
     identity: await readerIdentity(c, c.config),
@@ -3974,10 +4279,40 @@ async function archivePage(c) {
     headers: {
       ...POST_PAGE_SECURITY_HEADERS,
       "content-type": "text/html; charset=utf-8",
-      "cache-control": "public, max-age=3600"
+      // Checked with the app on every view, since the listing can change at any time: a page
+      // taken out of the archive must stop answering at once, and an unlisted link must start
+      // forwarding once its post is added (SPEC §5).
+      "cache-control": "no-cache",
+      ...post.email_only ? { "x-robots-tag": "noindex" } : {}
     }
   });
 }
+async function archivePage(c) {
+  const post = await getBySlug(c.env.DB, param(c, "slug"));
+  const send = post ? await publishedSendForPost(c.env.DB, post.id) : null;
+  if (!post || !send || !archiveAnswers({ emailOnly: post.email_only, webLink: send.web_link })) {
+    return nothingHereYetPage(c);
+  }
+  return postPage(c, post, send);
+}
+async function unlistedPage(c) {
+  const post = await getByUnlistedToken(c.env.DB, param(c, "token"));
+  const send = post ? await publishedSendForPost(c.env.DB, post.id) : null;
+  if (!post || !send) {
+    return nothingHereYetPage(c);
+  }
+  if (!post.email_only) {
+    return new Response(null, {
+      status: 302,
+      headers: {
+        location: archiveUrl(c.config, post.slug),
+        "cache-control": "no-store",
+        "x-robots-tag": "noindex"
+      }
+    });
+  }
+  return postPage(c, post, send);
+}
 
 // src/db/seed.ts
 function chunk(items, size) {
@@ -4036,13 +4371,15 @@ async function insertSuppressions(db, rows) {
 async function insertPost(db, post, revision) {
   await db.batch([
     db.prepare(
-      "INSERT INTO posts (id, slug, slug_auto, subject, status, current_revision, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?)"
+      "INSERT INTO posts (id, slug, slug_auto, unlisted_token, subject, status, email_only, current_revision, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)"
     ).bind(
       post.id,
       post.slug,
       post.slug_auto ? 1 : 0,
+      post.unlisted_token ?? null,
       post.subject,
       post.status,
+      post.email_only ? 1 : 0,
       post.current_revision,
       post.created_at,
       post.updated_at
@@ -4076,8 +4413,8 @@ async function insertImage(db, row) {
 async function insertSend(db, row) {
   await db.prepare(
     `INSERT INTO sends
-         (id, post_id, status, fire_at, rendered_html, rendered_text, subject, recipient_count, locked_until, scheduled_at, started_at, completed_at, audience_resolved_at, rev)
-       VALUES (?, ?, ?, ?, ?, ?, ?, ?, NULL, ?, ?, ?, ?, ${NEXT_REV})`
+         (id, post_id, status, fire_at, rendered_html, rendered_text, subject, recipient_count, locked_until, scheduled_at, started_at, completed_at, audience_resolved_at, web_link, rev)
+       VALUES (?, ?, ?, ?, ?, ?, ?, ?, NULL, ?, ?, ?, ?, 'unlisted', ${NEXT_REV})`
   ).bind(
     row.id,
     row.post_id,
@@ -4462,6 +4799,26 @@ async function deleteImageRow(db, postId, filename) {
   await db.prepare("DELETE FROM images WHERE post_id = ? AND filename = ?").bind(postId, filename).run();
 }
 
+// src/lib/slug_refusals.ts
+function slugRefusal(code) {
+  return code === "slug_invalid" ? refusal(
+    400,
+    "slug_invalid",
+    "Use lowercase letters and numbers, with single hyphens between words, up to 80 characters.",
+    { field: "slug" }
+  ) : refusal(409, "slug_taken", "Another post already has this address. Choose another.", {
+    field: "slug"
+  });
+}
+function slugPermanent(field, why2) {
+  return refusal(
+    409,
+    "slug_permanent",
+    why2 === "sent" ? "This post\u2019s archive address is fixed once it\u2019s sent, since people may have its link." : "This post\u2019s archive address is fixed: its scheduled email already links to it.",
+    { field }
+  );
+}
+
 // shared/cursor.ts
 var PATTERN = /^(\d+)\.(\d+)$/;
 function encodeSendCursor(cursor) {
@@ -4483,14 +4840,28 @@ function importNotice(db, importId, now) {
     "INSERT INTO notifications (send_id, import_id, kind, episode, created_at, updated_at) VALUES (NULL, ?, 'import', 0, ?, ?)"
   ).bind(importId, now, now);
 }
+function utcDayStart2(now) {
+  return Math.floor(now / 864e5) * 864e5;
+}
+async function sandboxNotice(db, now) {
+  await db.prepare(
+    "INSERT OR IGNORE INTO notifications (send_id, import_id, kind, episode, created_at, updated_at) VALUES (NULL, NULL, 'sandbox', ?, ?, ?)"
+  ).bind(utcDayStart2(now), now, now).run();
+}
 async function recordNotifications(db, now) {
   await db.prepare(
     `INSERT OR IGNORE INTO notifications (send_id, kind, episode, created_at, updated_at)
          SELECT id, 'finished', 0, ?1, ?1 FROM sends
           WHERE status = 'sent' AND completed_at >= ?2
          UNION ALL
-         SELECT id, 'refused', halted_at, ?1, ?1 FROM sends
+         SELECT id, 'refused', halted_at, ?1, ?1 FROM sends s
           WHERE status = 'sending' AND halt_reason = 'account' AND halted_at IS NOT NULL
+            AND NOT EXISTS (SELECT 1 FROM sends o
+                             WHERE o.status = 'sending' AND o.halt_reason = 'account'
+                               AND o.halted_at = s.halted_at AND o.id < s.id)
+            AND NOT EXISTS (SELECT 1 FROM notifications r
+                             WHERE r.kind = 'refused' AND r.episode = s.halted_at
+                               AND r.send_id <> s.id)
          UNION ALL
          SELECT id, 'missed', 0, ?1, ?1 FROM sends
           WHERE (status = 'scheduled' AND fire_at < ?1 - ?3)
@@ -4498,28 +4869,34 @@ async function recordNotifications(db, now) {
          UNION ALL
          SELECT id, 'wedged', 0, ?1, ?1 FROM sends WHERE ${WEDGED_SEND}
          UNION ALL
-         SELECT id, 'stuck', 0, ?1, ?1 FROM sends
-          WHERE status = 'sending' AND started_at < ?1 - ?4
-            AND halt_reason IS NOT 'account' AND NOT (${WEDGED_SEND})
-            AND NOT EXISTS (SELECT 1 FROM notifications r
-                             WHERE r.send_id = sends.id AND r.kind = 'refused')`
+         SELECT id, 'stuck', ${SEND_IDLE_SINCE}, ?1, ?1 FROM sends
+          WHERE ${stuckSendSql("?1 - ?4")}`
   ).bind(now, now - NOTIFY_HORIZON_MS, MISSED_THRESHOLD_MS, STUCK_THRESHOLD_MS).run();
 }
 async function dueNotifications(db, limit) {
   const { results } = await db.prepare(
     `SELECT n.send_id, n.import_id, n.kind, n.episode, n.attempts,
               s.subject, s.status AS send_status, s.fire_at, s.started_at, s.completed_at,
-              s.locked_until, s.halt_reason, s.halted_at, s.halt_cause, s.halt_error, s.c_pending, s.c_in_flight, s.c_accepted,
+              s.locked_until, s.halt_reason, s.halted_at, s.halt_retry_at, s.progress_at, s.halt_cause, s.halt_error, s.c_pending, s.c_in_flight, s.c_accepted,
               s.c_delivered, s.c_bounced, s.c_complained, s.c_skipped, s.c_unsent,
               i.file_name, i.created_at, i.attestation_version, i.counts, i.suppressions_added
          FROM notifications n
          LEFT JOIN sends s ON s.id = n.send_id
          LEFT JOIN imports i ON i.id = n.import_id
-        WHERE n.status = 'pending' AND (s.id IS NOT NULL OR i.id IS NOT NULL)
+        WHERE n.status = 'pending' AND (s.id IS NOT NULL OR i.id IS NOT NULL OR n.kind = 'sandbox')
         ORDER BY n.created_at ASC, n.send_id ASC, n.kind ASC
         LIMIT ?`
   ).bind(limit).all();
   return results.map((r) => {
+    if (r.kind === "sandbox") {
+      return {
+        send_id: null,
+        import_id: null,
+        kind: "sandbox",
+        episode: r.episode,
+        attempts: r.attempts
+      };
+    }
     if (r.kind === "import") {
       return {
         send_id: null,
@@ -4832,13 +5209,25 @@ function isWedged(send) {
   return send.status === "sending" && send.c_pending === 0 && send.c_in_flight > 0 && send.locked_until === null;
 }
 
+// src/send/stuck.ts
+function idleSince(send) {
+  if (send.status !== "sending" || send.started_at === null || isWedged(send)) {
+    return null;
+  }
+  return Math.max(send.progress_at ?? send.started_at, send.halt_retry_at ?? 0);
+}
+function stuckAt(send) {
+  const idle = idleSince(send);
+  return idle === null ? null : idle + STUCK_THRESHOLD_MS;
+}
+function isStuck(send, now) {
+  const at = stuckAt(send);
+  return at !== null && now > at;
+}
+
 // src/send/conditions.ts
 var minutes = (ms) => Math.max(1, Math.round(ms / 6e4));
 var plural = (n, one, many = `${one}s`) => `${n} ${n === 1 ? one : many}`;
-function sentence(error) {
-  const text = error?.trim() || "no detail given";
-  return /[.!?]$/.test(text) ? text : `${text}.`;
-}
 var action = (send, name) => ({
   name,
   method: "POST",
@@ -4904,37 +5293,38 @@ function sendConditions(send, now, day) {
     }
     const retried = !isWedged(send);
     if (retried && send.halt_reason === "account") {
-      const advice = refusalAdvice(send.halt_cause);
       out.push({
         kind: "refused",
         severity: "action",
         since: send.halted_at,
-        // No provider connected (SPEC §9) is held like a refusal but is no provider's doing,
-        // so it is said as what it is, with the fix once.
-        message: send.halt_cause === "not_connected" ? `No email provider is connected, so this send is held where it is. ${advice} No one has been marked unsent, and the send goes out at its first retry after a provider is connected.` : `The provider is refusing the account: ${sentence(send.halt_error)} ${advice} No one has been marked unsent, and the send resumes on its own at its next retry once the account is fixed.`,
+        message: refusedMessage(send.halt_cause, send.halt_error),
         action: null,
         cause: send.halt_cause,
         error: send.halt_error ?? "",
-        advice,
+        advice: refusalAdvice(send.halt_cause),
         retry_at: send.halt_retry_at
       });
     } else if (retried && send.halt_reason === "unavailable") {
       out.push({
         kind: "provider_unavailable",
-        severity: "info",
+        // A rate limit that outlasts any burst is the deployment's setting, which a person
+        // fixes, so it is worth a look rather than only shown.
+        severity: isSelfThrottled(send) ? "warn" : "info",
         since: send.halted_at,
-        message: `The provider is unavailable: ${sentence(send.halt_error)} The send retries on its own, spaced out the longer this lasts, and no one has been marked unsent.`,
+        message: unavailableMessage(send),
         action: null,
         error: send.halt_error ?? "",
         retry_at: send.halt_retry_at
       });
     }
-    if (send.started_at !== null && now - send.started_at > STUCK_THRESHOLD_MS) {
+    const stuck = stuckAt(send);
+    if (stuck !== null && now > stuck) {
+      const idle = now - (send.progress_at ?? send.started_at ?? now);
       out.push({
         kind: "stuck",
         severity: "warn",
-        since: send.started_at + STUCK_THRESHOLD_MS,
-        message: `Still sending ${plural(minutes(now - send.started_at), "minute")} after it started; it may be retrying.`,
+        since: stuck,
+        message: `Nothing has gone out for ${plural(minutes(idle), "minute")}, with no retry or provider problem to explain it. Sending may have stopped, or another send may be taking its turn. It picks up where it stopped, mailing no one twice.`,
         action: null
       });
     }
@@ -4951,6 +5341,17 @@ function sendConditions(send, now, day) {
       rate
     });
   }
+  const heard = send.c_delivered + send.c_bounced + send.c_complained;
+  if (send.status === "sent" && send.completed_at !== null && now - send.completed_at > NO_RECEIPTS_AFTER_MS && now - send.completed_at <= BOUNCE_SPIKE_RECENT_MS && send.c_accepted > 0 && heard === 0) {
+    out.push({
+      kind: "no_receipts",
+      severity: "warn",
+      since: send.completed_at + NO_RECEIPTS_AFTER_MS,
+      message: `No delivery receipt has arrived for any of the ${plural(send.c_accepted, "recipient")} the provider took, ${plural(Math.round((now - send.completed_at) / 36e5) || 1, "hour")} after the send went out. The provider's events may not be reaching this app, so its bounces and complaints suppress no one. Check the webhook and the app's error log.`,
+      action: null,
+      accepted: send.c_accepted
+    });
+  }
   return out.sort(bySeverity);
 }
 
@@ -4977,18 +5378,13 @@ function nextChangeAt(send, now) {
   if (send.locked_until !== null && send.locked_until > now) {
     return now;
   }
-  let next = null;
   if (isWedged(send)) {
-  } else if (send.halt_retry_at !== null) {
-    next = Math.max(now, send.halt_retry_at - HALT_RETRY_SLACK_MS);
-  } else {
-    return now;
+    return null;
   }
-  const stuckAt = send.started_at === null ? null : send.started_at + STUCK_THRESHOLD_MS;
-  if (stuckAt !== null && stuckAt >= now) {
-    next = next === null ? stuckAt : Math.min(next, stuckAt);
+  if (send.halt_retry_at !== null) {
+    return Math.max(now, send.halt_retry_at - HALT_RETRY_SLACK_MS);
   }
-  return next;
+  return now;
 }
 function feedPace(sends, settlingSince, now) {
   let moving = false;
@@ -5019,7 +5415,7 @@ function readAgainAt(pace, now) {
 }
 
 // src/send/view.ts
-function derivePhase(status, counts2, hasRetries, due, wedged, refused, unavailable2) {
+function derivePhase(status, counts2, hasRetries, due, wedged, refused, unavailable2, audienceFixed) {
   switch (status) {
     case "scheduled":
       return due ? "due" : "scheduled";
@@ -5031,10 +5427,13 @@ function derivePhase(status, counts2, hasRetries, due, wedged, refused, unavaila
       if (wedged || refused) {
         return "needs-attention";
       }
+      if (unavailable2 && (counts2.pending > 0 || !audienceFixed)) {
+        return "backing-off";
+      }
       if (counts2.in_flight > 0) {
         return hasRetries ? "retrying" : "progressing";
       }
-      if (counts2.pending > 0 && (hasRetries || unavailable2)) {
+      if (counts2.pending > 0 && hasRetries) {
         return "backing-off";
       }
       return "progressing";
@@ -5080,6 +5479,7 @@ function tickEstimate(startedAt, total, done, running, now) {
 }
 function buildSendView(send, config, hasRetries, now, day) {
   const counts2 = countsOf(send);
+  const published = send.status === "sending" || send.status === "sent";
   const summed = counts2.pending + counts2.in_flight + counts2.accepted + counts2.delivered + counts2.bounced + counts2.complained + counts2.skipped + counts2.unsent;
   const total = summed > 0 ? summed : send.recipient_count;
   const done = Math.max(0, total - counts2.pending - counts2.in_flight);
@@ -5104,13 +5504,24 @@ function buildSendView(send, config, hasRetries, now, day) {
   } : null;
   const refused = halt?.reason === "account";
   const unavailable2 = halt?.reason === "unavailable";
-  const phase = derivePhase(send.status, counts2, hasRetries, due, wedged, refused, unavailable2);
-  const handingOff = phase === "progressing" || phase === "retrying";
+  const phase = derivePhase(
+    send.status,
+    counts2,
+    hasRetries,
+    due,
+    wedged,
+    refused,
+    unavailable2,
+    send.audience_resolved_at !== null
+  );
+  const handingOff = (phase === "progressing" || phase === "retrying") && !isStuck(send, now);
   return {
     id,
     post_id: send.post_id,
     subject: send.subject,
     status: send.status,
+    email_only: send.post_email_only === 1,
+    web_link: send.web_link,
     rev: send.rev,
     as_of: now,
     fire_at: send.fire_at,
@@ -5144,8 +5555,10 @@ function buildSendView(send, config, hasRetries, now, day) {
       deliveries: `/api/sends/${id}/deliveries`,
       deliveries_csv: `/api/sends/${id}/deliveries.csv`,
       post: `/api/posts/${send.post_id}`,
-      // The archive serves a post's page once its send starts: before, the link would 404.
-      archive: (send.status === "sending" || send.status === "sent") && send.post_slug !== null ? archiveUrl(config, send.post_slug) : null
+      // Each address answers only once the send starts; the archive's only while the post is
+      // listed, or whatever the listing for an email that carries it (`archiveAnswers`).
+      archive: published && send.post_slug !== null && archiveAnswers({ emailOnly: send.post_email_only === 1, webLink: send.web_link }) ? archiveUrl(config, send.post_slug) : null,
+      unlisted: published && send.post_unlisted_token !== null ? unlistedPostUrl(config.appOrigin, send.post_unlisted_token) : null
     }
   };
 }
@@ -5184,7 +5597,12 @@ async function renderPost(env, config, post, branding) {
   }
   const images = await listImages(env.DB, post.id);
   const rendered = await render({ post, revision, images }, config, branding);
-  return { rendered_html: rendered.html, rendered_text: rendered.text, subject: rendered.subject };
+  return {
+    rendered_html: rendered.html,
+    rendered_text: rendered.text,
+    subject: rendered.subject,
+    warnings: rendered.warnings
+  };
 }
 var MINUTE_MS = 60 * 1e3;
 function onTheMinute(fireAt) {
@@ -5199,8 +5617,8 @@ function acceptFireAt(requested, minLeadMs, { now = Date.now() } = {}) {
   return onTheMinute(requested);
 }
 var FREEZE_RETRIES = 3;
-var ACTIVE_SEND_EXISTS = "This post already has a send scheduled or going out. Reschedule or cancel that send instead.";
-async function freeze(env, config, post, fireAt) {
+var ACTIVE_SEND_EXISTS = "This post already has a send scheduled or going out. Edit its schedule or cancel it instead.";
+async function freeze(env, config, post, fireAt, postSettings = {}) {
   const active = await getActiveSendForPost(env.DB, post.id);
   if (active) {
     throw await activeSendExists(env, active);
@@ -5209,7 +5627,7 @@ async function freeze(env, config, post, fireAt) {
     throw refusal(
       409,
       "post_not_draft",
-      post.status === "sent" ? "This post has already been sent, so it can\u2019t be scheduled again." : "This post is already scheduled. Reschedule or cancel its send instead."
+      post.status === "sent" ? "This post has already been sent, so it can\u2019t be scheduled again." : "This post is already scheduled. Edit its schedule or cancel it instead."
     );
   }
   if (!post.subject.trim()) {
@@ -5224,6 +5642,10 @@ async function freeze(env, config, post, fireAt) {
     const now = Date.now();
     const id = newId();
     const settingsVersion = version ?? 0;
+    const listing = publishingChanges(post, postSettings) ? [
+      setPublishingStmt(env.DB, post, postSettings, settingsVersionIs(settingsVersion)),
+      stampSendsOfPostStmt(env.DB, post.id)
+    ] : [];
     let results;
     try {
       results = await env.DB.batch([
@@ -5240,9 +5662,13 @@ async function freeze(env, config, post, fireAt) {
           "scheduled",
           now,
           settingsVersionIs(settingsVersion)
-        )
+        ),
+        ...listing
       ]);
     } catch (err) {
+      if (isSlugCollision(err)) {
+        throw slugRefusal("slug_taken");
+      }
       if (isActiveSendConflict(err)) {
         const winner = await getActiveSendForPost(env.DB, post.id);
         throw winner ? await activeSendExists(env, winner) : refusal(409, "active_send_exists", ACTIVE_SEND_EXISTS);
@@ -5276,8 +5702,8 @@ async function readForAction(env, sendId) {
   return send;
 }
 async function windowClosed(env, send, what) {
-  const why = send.status === "scheduled" ? "its fire time has passed and it\u2019s about to send" : `it\u2019s ${send.status}`;
-  return refusal(409, "window_closed", `This send can no longer be ${what}: ${why}.`, {
+  const why2 = send.status === "scheduled" ? "its fire time has passed and it\u2019s about to send" : `it\u2019s ${send.status}`;
+  return refusal(409, "window_closed", `This send can no longer be ${what}: ${why2}.`, {
     send: await viewSend(env, send.id)
   });
 }
@@ -5340,6 +5766,9 @@ async function cancel(env, sendId) {
   return { send: unwrap(await getSend(env.DB, sendId), "send"), changed: true };
 }
 
+// demo/posts/0-test-email/index.md
+var test_email_default = "---\nsubject: Test email\nslug: test-email\nstatus: sent\nemail_only: true\nsent_to: proof@fieldnotes.example\n---\n\n# Test email\n\nThis is the test send that proved Field Notes works end to end, before its list came in: subscribing, confirming, scheduling, and a real send landing in a real inbox.\n\nIt went out as email only, so it isn't in the archive or on the home page. Its web version still opens from the email, which is how you're reading this.\n";
+
 // demo/posts/1-the-hovering-hunter/index.md
 var the_hovering_hunter_default = "---\nsubject: The hovering hunter\nslug: the-hovering-hunter\nstatus: sent\n---\n\n# The hovering hunter\n\nWelcome to Field Notes, a demo publication of the Kestrel application. Everything here, from the subscribers to the sends to this archive, is sample data, so look around and change whatever you like.\n\nThe app is named after a small falcon called a [kestrel](https://en.wikipedia.org/wiki/Common_kestrel). One way to spot a kestrel is by how it hunts, using a technique called wind-hovering. The bird faces into the wind and hovers in place, watching the ground below for prey. Here's what a kestrel looks like:\n\n![A male Canarian kestrel in flight, wings spread over a green field](kestrel.webp)\n\n*A male Canarian kestrel in strong wind. Taken in Funchal, Madeira by [u/treecreaper](https://www.reddit.com/r/birdsofprey/comments/1rlew5p/canarian_kestrel/).*\n\nTo see what Kestrel can do, open the dashboard and try editing one of the drafts.\n";
 
@@ -5353,7 +5782,7 @@ var publishing_default = "---\nsubject: Publishing\nslug: publishing\nstatus: se
 var working_with_robots_default = "---\nsubject: Working with robots\nslug: working-with-robots\nstatus: sent\n---\n\n# Working with robots\n\nGive Claude a piece of writing and ask it to schedule an email to the list for Friday morning, and it does the thing you asked for.\n\nKestrel is a full-fledged application built for publishers, and it's designed with this in mind:\n\n1. Posts are written in Markdown.\n2. Everything is built on an API.\n3. The app's interface and Claude both use that API, so anything you can do in the editor, you can ask Claude to do.\n\nPublishing and scheduling can be stressful, especially when it comes to last-minute edits. With Kestrel, you can ask Claude to proofread and schedule for you, and trust that it's done right.\n\nThe next issue for this demo publication is already scheduled. You can find it in the dashboard.\n";
 
 // demo/posts/5-a-quick-note/index.md
-var a_quick_note_default = "---\nsubject: A quick note\nslug: a-quick-note\nstatus: scheduled\n---\n\n# A quick note\n\nNot every issue has to be long. Sometimes the best newsletter is a quick note that there's something new to read, watch, or listen to.\n\nThanks for reading Field Notes.\n";
+var a_quick_note_default = "---\nsubject: A quick note\nslug: a-quick-note\nstatus: scheduled\n---\n\n# A quick note\n\nNot every issue has to be long. Sometimes the best newsletter is a quick note that there's something new to read, watch, or listen to.\n\nA note like this one doesn't always belong in your archive. To send it as email only, uncheck **Include in archive** in its Post settings.\n\nThanks for reading Field Notes.\n";
 
 // demo/posts/6-try-editing-this-draft/index.md
 var try_editing_this_draft_default = "---\nsubject: Try editing this draft\nslug: try-editing-this-draft\nstatus: draft\nedited: 2 days ago\n---\n\n# Try editing this draft\n\n*(Draft. Nobody has seen this but you.)*\n\nThis post is here to experiment on. Change a word, add a heading, drop in an image, and watch the preview follow.\n\nA few things to try:\n\n- **Preview** shows the email exactly as a subscriber will get it.\n- **Send test** mails it to the test inboxes in Settings. In this demo they're `fieldnotes.example` addresses, which never reach a real inbox.\n- **Schedule** puts it in the queue behind the review window.\n\nNothing you do to a draft reaches the list until you schedule it and its window closes.\n";
@@ -5414,7 +5843,12 @@ function postImages(markdown2) {
 function parseDemoPost(bundle, text) {
   const file = `demo/posts/${bundle}/index.md`;
   const { fields, body } = parseFrontMatter(file, text);
-  const f = readFields(file, fields, ["subject", "slug", "status"], ["edited"]);
+  const f = readFields(
+    file,
+    fields,
+    ["subject", "slug", "status"],
+    ["edited", "email_only", "sent_to"]
+  );
   const status = f.status;
   if (!STATUSES.includes(status)) {
     throw new Error(`${file}: status must be sent, scheduled, or draft, not "${f.status}"`);
@@ -5427,6 +5861,20 @@ function parseDemoPost(bundle, text) {
     }
     editedDaysAgo = Number(days[1]);
   }
+  let emailOnly;
+  if (f.email_only != null) {
+    if (f.email_only !== "true" && f.email_only !== "false" || status === "draft") {
+      throw new Error(`${file}: "email_only" is true or false, on a sent or scheduled post`);
+    }
+    emailOnly = f.email_only === "true";
+  }
+  let sentTo;
+  if (f.sent_to != null) {
+    sentTo = f.sent_to.split(",").map((a) => a.trim()).filter(Boolean);
+    if (status !== "sent" || !sentTo.length || sentTo.some((a) => !a.endsWith(".example"))) {
+      throw new Error(`${file}: "sent_to" is for sent posts, a list of .example addresses`);
+    }
+  }
   if (!body) {
     throw new Error(`${file}: the post has no body`);
   }
@@ -5438,7 +5886,9 @@ function parseDemoPost(bundle, text) {
     status,
     markdown: body,
     images: postImages(body),
-    ...editedDaysAgo != null ? { editedDaysAgo } : {}
+    ...editedDaysAgo != null ? { editedDaysAgo } : {},
+    ...emailOnly != null ? { emailOnly } : {},
+    ...sentTo ? { sentTo } : {}
   };
 }
 function parseDemoPublication(file, text) {
@@ -5453,6 +5903,7 @@ function parseDemoPublication(file, text) {
 }
 function loadDemo() {
   const posts = [
+    ["0-test-email", test_email_default],
     ["1-the-hovering-hunter", the_hovering_hunter_default],
     ["2-an-old-fashioned-list", an_old_fashioned_list_default],
     ["3-publishing", publishing_default],
@@ -5477,9 +5928,11 @@ function demoPostId(position) {
 function buildTimeline(now) {
   const first = now - 26 * DAY;
   const send2At = first + WEEK;
+  const importAt = first - 12 * DAY;
   return {
     now,
-    importAt: first - 12 * DAY,
+    testSendAt: importAt - 2 * DAY,
+    importAt,
     bounceAt: send2At + DAY,
     complaintAt: send2At + 2 * DAY,
     scheduledFireAt: onTheMinute(now + 2 * DAY),
@@ -5991,14 +6444,31 @@ function buildDeliveries(sendId, audience, sentAt, events, unsentSlots) {
     return base;
   });
 }
+function testRecipients(posts, t) {
+  const emails = [...new Set(posts.flatMap((p) => p.sentTo ?? []))];
+  return emails.map((email2) => ({
+    id: newId(),
+    email: email2,
+    status: "unsubscribed",
+    confirm_token: newToken(),
+    confirm_sent_at: t.testSendAt - HOUR,
+    unsub_token: newToken(),
+    created_at: t.testSendAt - HOUR,
+    confirmed_at: t.testSendAt - 50 * 60 * 1e3,
+    unsubscribed_at: t.testSendAt + 2 * HOUR
+  }));
+}
 function renderInputFor(id, demoPost, at, markdown2) {
   const post = {
     id,
     slug: demoPost.slug,
     // A demo slug that is just its subject's reads as following it, as a new post's would.
     slug_auto: demoPost.slug === slugify(demoPost.subject),
+    // Made here rather than by the database, since the render below carries it.
+    unlisted_token: newUnlistedToken(),
     subject: demoPost.subject,
     status: demoPost.status,
+    email_only: demoPost.emailOnly ?? false,
     current_revision: `${id}-rev`,
     created_at: at,
     updated_at: at
@@ -6018,7 +6488,7 @@ async function seedDatabase(env, config, imageFiles = [], logoFile, options) {
   const now = Date.now();
   const timeline = buildTimeline(now);
   const demo = loadDemo();
-  const sentPosts = demo.posts.filter((p) => p.status === "sent").length;
+  const sentPosts = demo.posts.filter((p) => p.status === "sent" && !p.sentTo).length;
   if (sentPosts > timeline.sentAt.length) {
     throw new Error(
       `demo/posts has ${sentPosts} sent posts, but the seed timeline has ${timeline.sentAt.length} sends`
@@ -6045,6 +6515,7 @@ async function seedDatabase(env, config, imageFiles = [], logoFile, options) {
   const size = options?.size;
   const rand = makePrng(options?.seed ?? DEFAULT_SEED);
   const built = size != null ? buildScaledAudience(timeline, size, rand) : buildAudience(timeline);
+  built.subscribers.push(...testRecipients(demo.posts, timeline));
   await insertSubscribers(db, built.subscribers);
   await insertSuppressions(db, built.suppressions);
   const audience = await audienceEmails(db);
@@ -6121,6 +6592,37 @@ async function seedDatabase(env, config, imageFiles = [], logoFile, options) {
       counts2.scheduled++;
       continue;
     }
+    if (demoPost.sentTo) {
+      const sentAt = timeline.testSendAt;
+      const fireAt2 = onTheMinute(sentAt) - 60 * 1e3;
+      const { post: post2, revision: revision2 } = renderInputFor(id, demoPost, sentAt, markdown2);
+      const result2 = await render({ post: post2, revision: revision2, images }, config, branding);
+      await insertPostWithImages(post2, revision2);
+      const sendId2 = newId();
+      await insertSend(db, {
+        id: sendId2,
+        post_id: id,
+        status: "sent",
+        fire_at: fireAt2,
+        rendered_html: result2.html,
+        rendered_text: result2.text,
+        subject: result2.subject,
+        recipient_count: demoPost.sentTo.length,
+        scheduled_at: fireAt2 - 6 * 60 * 1e3,
+        // Send now: the minimum lead, then the minute
+        started_at: fireAt2,
+        completed_at: sentAt
+      });
+      const deliveries3 = buildDeliveries(sendId2, demoPost.sentTo, sentAt, /* @__PURE__ */ new Map(), /* @__PURE__ */ new Set());
+      await insertDeliveries(db, deliveries3);
+      await recomputeSendCounters(db, sendId2);
+      counts2.sent++;
+      counts2.deliveries += deliveries3.length;
+      if (!demoPost.emailOnly) {
+        archiveUrls.push(`${config.archiveOrigin}${config.archiveBasePath}/${demoPost.slug}`);
+      }
+      continue;
+    }
     const completedAt = unwrap(timeline.sentAt[sentIndex], "send timeline slot");
     const sentAudience = unwrap(built.sentAudiences[sentIndex], "frozen send audience");
     const fireAt = onTheMinute(completedAt) - 60 * 1e3;
@@ -6149,7 +6651,9 @@ async function seedDatabase(env, config, imageFiles = [], logoFile, options) {
     await recomputeSendCounters(db, sendId);
     counts2.sent++;
     counts2.deliveries += deliveries2.length;
-    archiveUrls.push(`${config.archiveOrigin}${config.archiveBasePath}/${demoPost.slug}`);
+    if (!demoPost.emailOnly) {
+      archiveUrls.push(`${config.archiveOrigin}${config.archiveBasePath}/${demoPost.slug}`);
+    }
     sentIndex++;
   }
   const bucket = (status) => built.subscribers.filter((s) => s.status === status).length;
@@ -6237,25 +6741,25 @@ async function reset(c) {
 import { Lexer } from "marked";
 
 // docs/get-started/02-deploy.md
-var deploy_default = '# Deploy the app\n\nKestrel runs as one Cloudflare Worker, with a D1 database for posts and subscribers and an R2 bucket for images.\n\nIn this guide, you choose your hostnames, create your instance\'s repository, create the database and the bucket, and point Kestrel\'s production settings at them and at your hostname. Then you deploy, and check that the app answers on your hostname.\n\n## Before you begin\n\n- A [Cloudflare account](https://dash.cloudflare.com/sign-up), with your domain\'s DNS on Cloudflare. Your app\'s hostname and its login both live there.\n- [Node.js](https://nodejs.org/) 22 or later, and [Git](https://git-scm.com/).\n- A GitHub account, or another Git host, for your instance\'s repository.\n- An [AWS account](https://portal.aws.amazon.com/billing/signup), for Amazon SES, which sends your email.\n\n## Choose your hostnames\n\nKestrel uses two hostnames: one for the app, and one your email is sent from.\n\n| Hostname | What it\'s for |\n| --- | --- |\n| `newsletter.example.com` | the editor, the API, and the public pages readers see |\n| `send.example.com` | the address your email comes from, and its SPF, DKIM, and DMARC records |\n\nThese guides put the app on a subdomain, which leaves any website you already have on `example.com` untouched. If `example.com` has no website of its own, the app can live there instead. Use `example.com` wherever these guides say `newsletter.example.com`.\n\nIt\'s recommended to send from a subdomain rather than from `example.com` itself. Your apex domain carries the reputation of your regular email, and a newsletter shouldn\'t put that at risk. Avoid `mail.` as the sending name too, since mail servers read it as an inbound host. [Sending-domain DNS](../reference/02-sending-domain-dns.md#choose-your-sending-name) explains both.\n\nThroughout these guides, replace the example names with your own, and any value written as `REPLACE_WITH_\u2026`.\n\n## 1. Create your instance\'s repository\n\nYour instance\'s repository holds its configuration, its database migrations, and the release of Kestrel it runs. Kestrel itself installs from npm as `@kurtbruns/kestrel`, so the repository stays small, and an upgrade changes the version it names.\n\n1. On GitHub, [create a new repository](https://github.com/new) named `newsletter`. It can be private. Leave it empty, with no README, license, or `.gitignore`.\n\n1. Clone it, and write a new instance into it. Replace `YOUR_USERNAME` with your GitHub username:\n\n    ```bash\n    git clone https://github.com/YOUR_USERNAME/newsletter.git\n    cd newsletter\n    npx @kurtbruns/kestrel init\n    ```\n\n    This writes the instance\'s files: `wrangler.jsonc` for its settings, `package.json` with the release it runs, the release\'s database migrations, and a starting point for Claude Code in `.claude/`. The instance\'s `README.md` lists its commands.\n\n1. Install the release and its tools:\n\n    ```bash\n    npm install\n    ```\n\n1. Commit the new instance, and push it:\n\n    ```bash\n    git add -A\n    git commit -m "Start a Kestrel instance"\n    git push -u origin HEAD\n    ```\n\n1. **(Optional)** Try Kestrel locally before you deploy it. Your instance is written and installed, so start at [Start the app](../guides/08-try-locally.md#2-start-the-app), and come back here when you\'re done. Email goes to a stand-in, so nothing reaches a real inbox.\n\n## 2. Sign in to Cloudflare\n\nEvery command from here on acts on your Cloudflare account through the Wrangler CLI.\n\n1. Sign in. A browser window opens for you to approve the login:\n\n    ```bash\n    npx wrangler login\n    ```\n\n1. Confirm which account you\'re signed in to:\n\n    ```bash\n    npx wrangler whoami\n    ```\n\n    It prints your email and the account name. If you belong to more than one account, make sure it\'s the one that holds your domain.\n\n## 3. Create the database and the image bucket\n\nEach command creates the resource and writes its id or name into the `production` block of `wrangler.jsonc`, under the binding the app already uses, so there\'s nothing to copy.\n\n1. Create the database:\n\n    ```bash\n    npx wrangler d1 create kestrel-production --env production --binding DB --update-config\n    ```\n\n    It prints the new database\'s settings, then a snippet it says to add to your configuration. Wrangler has already added it: it fills in the `database_id` of the production `DB` binding with the database\'s real id, in place of `REPLACE_WITH_PRODUCTION_D1_ID`, so there\'s nothing to paste.\n\n1. Create the bucket for images:\n\n    ```bash\n    npx wrangler r2 bucket create kestrel-media-production --env production --binding MEDIA --update-config\n    ```\n\n    It prints a snippet to add to your configuration too. There\'s nothing to paste here either: the production `MEDIA` binding already names this bucket, so it stays as it is.\n\nWrangler rewrites the whole of `wrangler.jsonc` in its own layout when it saves: tabs, and one value per line. Your comments and settings stay; only the spacing changes.\n\nName `--env production` on every Wrangler command that creates or binds a resource. Without it, Wrangler writes to the top level, which is local development.\n\n## 4. Configure production\n\n`wrangler.jsonc` holds two sets of settings. The top level is for local development, so leave it alone. The `production` block under `env` is yours to fill in.\n\n1. Open `wrangler.jsonc` and change the values marked here in the `production` block. It\'s shown compactly here; in your file, after section 3, each value is on its own line:\n\n    ```jsonc\n    "production": {\n      "routes": [{ "pattern": "newsletter.example.com", "custom_domain": true }], // \u2190 your app\'s hostname\n      "d1_databases": [\n        {\n          "binding": "DB",\n          "database_name": "kestrel-production",\n          "database_id": "\u2026", // already filled in by section 3; leave it\n          "migrations_dir": "migrations"\n        }\n      ],\n      "vars": {\n        "PROVIDER": "",                                            // \u2190 stays empty until step 3\n        "APP_ORIGIN": "https://newsletter.example.com",            // \u2190 your app\'s hostname\n        "ARCHIVE_BASE_PATH": "/archive",\n        "SENDING_DOMAIN": "send.example.com",                      // \u2190 your sending hostname\n        "FROM_ADDRESS": "Newsletter <newsletter@send.example.com>" // \u2190 who your mail is from\n      }\n    }\n    ```\n\n    What each one does:\n\n    - **`routes`** puts the app on your hostname when you deploy. Cloudflare creates the DNS record and the certificate. Your domain must be in the same Cloudflare account, and the hostname can\'t already have a CNAME record; delete one if it does. The block also turns off the `workers.dev` addresses, so the app answers only on your hostname.\n    - **`PROVIDER` stays empty.** Step 3, [Connect Amazon SES](04-ses.md), sets it. Until then the app runs without an email provider: you can write and preview posts, but scheduling, test emails, and signups are refused. Never set it to `fake`, the top level\'s value, even when a wrangler warning suggests copying it: `fake` delivers nothing, and the app refuses it on your hostname.\n    - **`ARCHIVE_BASE_PATH`** is permanent once you send. Every post you send carries its `/archive/\u2026` link, and changing the prefix later breaks the links you\'ve already mailed. Keep `/archive` unless you have a reason not to.\n    - **`FROM_ADDRESS`** is the address every email comes from. Keep it on your sending hostname, and set `SENDING_DOMAIN` to the part after the `@`.\n\n    Change every `example.com` value, the route included, even before you connect a provider. The app checks its settings but can\'t see the route: it refuses to run while `APP_ORIGIN`, `SENDING_DOMAIN`, or `FROM_ADDRESS`, or `ARCHIVE_ORIGIN` or `MEDIA_PUBLIC_BASE` if you set them, is still on `example.com`, since its links and the address your email comes from would name a domain that isn\'t yours.\n\n    Every other setting has a working default. [Configuration](../reference/01-configuration.md) lists them all, and what the app refuses.\n\n1. Check the file. This regenerates the binding types, and fails if the configuration doesn\'t parse:\n\n    ```bash\n    npm run typecheck\n    ```\n\n    Wrangler prints the binding types it generated and ends with a reminder to run it again whenever you change `wrangler.jsonc`. The type check that follows prints nothing when it passes.\n\n1. Commit your settings and push them to your repository. An upgrade changes only the release your instance runs, so your settings stay as they are:\n\n    ```bash\n    git commit -am "Configure production"\n    git push\n    ```\n\n## 5. Apply the schema\n\nCreate Kestrel\'s tables in the production 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. It applies only the ones the database hasn\'t seen, so running it again is harmless.\n\n## 6. Deploy\n\n```bash\nnpx wrangler deploy --env production\n```\n\nThis deploys the release your instance runs, with your settings. The output ends with the hostname the app now answers on. Deploying also registers the once-a-minute schedule that sends posts, which you can see under the Worker\'s **Triggers** tab in the Cloudflare dashboard.\n\n## Check it\n\n1. The app answers on your hostname. A new hostname can take a few minutes to get its certificate.\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\n1. The editor is locked. Until you set up Access in the next step, the app can\'t tell who is asking, so it lets no one in:\n\n    ```bash\n    curl -s -o /dev/null -w "%{http_code}\\n" https://newsletter.example.com/api/whoami\n    ```\n\n    ```\n    401\n    ```\n\n    In a browser, `https://newsletter.example.com/dashboard/` says the editor is locked until you set up Access. That\'s expected.\n\n1. In a browser, `https://newsletter.example.com/` shows your newsletter\'s public landing page. Its subscribe page, `/subscribe`, says signups aren\'t open yet, until step 3, Connect Amazon SES.\n\nIf the public pages instead say the newsletter is temporarily unavailable, and `/health` answers `500` with a body like `{"error":"invalid_config","variable":"APP_ORIGIN",\u2026}`, the setting it names is missing, malformed, or still on `example.com`. Fix it in `wrangler.jsonc`, commit, and deploy again.\n\nIf the public pages say the same, but `/health` answers `500` with `{"error":"schema_behind","missing":[\u2026],\u2026}`, the database hasn\'t run the migrations it lists, most often because step 5 was skipped or its prompt answered no. Run step 5\'s command, which the body\'s `message` repeats; the app answers as soon as it finishes, with no new deploy.\n\nNext, [lock the dashboard with Access](03-access.md).\n';
+var deploy_default = '# Deploy the app\n\nKestrel runs as one Cloudflare Worker, with a D1 database for posts and subscribers and an R2 bucket for images.\n\nIn this guide, you choose your hostnames, create your instance\'s repository, create the database and the bucket, and point Kestrel\'s production settings at them and at your hostname. Then you deploy, and check that the app answers on your hostname.\n\n## Before you begin\n\n- A [Cloudflare account](https://dash.cloudflare.com/sign-up), with your domain\'s DNS on Cloudflare. Your app\'s hostname and its login both live there.\n- [Node.js](https://nodejs.org/) 22 or later, and [Git](https://git-scm.com/).\n- A GitHub account, or another Git host, for your instance\'s repository.\n- An [AWS account](https://portal.aws.amazon.com/billing/signup), for Amazon SES, which sends your email.\n\n## Choose your hostnames\n\nKestrel uses two hostnames: one for the app, and one your email is sent from.\n\n| Hostname | What it\'s for |\n| --- | --- |\n| `newsletter.example.com` | the editor, the API, and the public pages readers see |\n| `send.example.com` | the address your email comes from, and its SPF, DKIM, and DMARC records |\n\nThese guides put the app on a subdomain, which leaves any website you already have on `example.com` untouched. If `example.com` has no website of its own, the app can live there instead. Use `example.com` wherever these guides say `newsletter.example.com`.\n\nIt\'s recommended to send from a subdomain rather than from `example.com` itself. Your apex domain carries the reputation of your regular email, and a newsletter shouldn\'t put that at risk. Avoid `mail.` as the sending name too, since mail servers read it as an inbound host. [Sending-domain DNS](../reference/02-sending-domain-dns.md#choose-your-sending-name) explains both.\n\nThroughout these guides, replace the example names with your own, and any value written as `REPLACE_WITH_\u2026`.\n\n## 1. Create your instance\'s repository\n\nYour instance\'s repository holds its configuration, its database migrations, and the release of Kestrel it runs. Kestrel itself installs from npm as `@kurtbruns/kestrel`, so the repository stays small, and an upgrade changes the version it names.\n\n1. On GitHub, [create a new repository](https://github.com/new) named `newsletter`. It can be private. Leave it empty, with no README, license, or `.gitignore`.\n\n1. Clone it, and write a new instance into it. Replace `YOUR_USERNAME` with your GitHub username:\n\n    ```bash\n    git clone https://github.com/YOUR_USERNAME/newsletter.git\n    cd newsletter\n    npx @kurtbruns/kestrel init\n    ```\n\n    This writes the instance\'s files: `wrangler.jsonc` for its settings, `package.json` with the release it runs, the release\'s database migrations, and a starting point for Claude Code in `.claude/`. The instance\'s `README.md` lists its commands.\n\n1. Install the release and its tools:\n\n    ```bash\n    npm install\n    ```\n\n1. Commit the new instance, and push it:\n\n    ```bash\n    git add -A\n    git commit -m "Start a Kestrel instance"\n    git push -u origin HEAD\n    ```\n\n1. **(Optional)** Try Kestrel locally before you deploy it. Copy the local settings, and start the app:\n\n    ```bash\n    cp .dev.vars.example .dev.vars\n    npm run dev\n    ```\n\n    Open http://localhost:8787/dashboard/, and run `npm run seed` in a second terminal to load a demo publication. Email goes to a stand-in, so nothing reaches a real inbox. Stop the server with <kbd>Ctrl</kbd>+<kbd>C</kbd> when you\'re done.\n\n## 2. Sign in to Cloudflare\n\nEvery command from here on acts on your Cloudflare account through the Wrangler CLI.\n\n1. Sign in. A browser window opens for you to approve the login:\n\n    ```bash\n    npx wrangler login\n    ```\n\n1. Confirm which account you\'re signed in to:\n\n    ```bash\n    npx wrangler whoami\n    ```\n\n    It prints your email and the account name. If you belong to more than one account, make sure it\'s the one that holds your domain.\n\n## 3. Create the database and the image bucket\n\nEach command creates the resource and writes its id or name into the `production` block of `wrangler.jsonc`, under the binding the app already uses, so there\'s nothing to copy.\n\n1. Create the database:\n\n    ```bash\n    npx wrangler d1 create kestrel-production --env production --binding DB --update-config\n    ```\n\n    It prints the new database\'s settings, then a snippet it says to add to your configuration. Wrangler has already added it: it fills in the `database_id` of the production `DB` binding with the database\'s real id, in place of `REPLACE_WITH_PRODUCTION_D1_ID`, so there\'s nothing to paste.\n\n1. Create the bucket for images:\n\n    ```bash\n    npx wrangler r2 bucket create kestrel-media-production --env production --binding MEDIA --update-config\n    ```\n\n    It prints a snippet to add to your configuration too. There\'s nothing to paste here either: the production `MEDIA` binding already names this bucket, so it stays as it is.\n\nWrangler rewrites the whole of `wrangler.jsonc` in its own layout when it saves: tabs, and one value per line. Your comments and settings stay; only the spacing changes.\n\nName `--env production` on every Wrangler command that creates or binds a resource. Without it, Wrangler writes to the top level, which is local development.\n\n## 4. Configure production\n\n`wrangler.jsonc` holds two sets of settings. The top level is for local development, so leave it alone. The `production` block under `env` is yours to fill in.\n\n1. Open `wrangler.jsonc` and change the values marked here in the `production` block. It\'s shown compactly here; in your file, after section 3, each value is on its own line:\n\n    ```jsonc\n    "production": {\n      "routes": [{ "pattern": "newsletter.example.com", "custom_domain": true }], // \u2190 your app\'s hostname\n      "d1_databases": [\n        {\n          "binding": "DB",\n          "database_name": "kestrel-production",\n          "database_id": "\u2026", // already filled in by section 3; leave it\n          "migrations_dir": "migrations"\n        }\n      ],\n      "vars": {\n        "PROVIDER": "",                                            // \u2190 stays empty until Connect Amazon SES\n        "APP_ORIGIN": "https://newsletter.example.com",            // \u2190 your app\'s hostname\n        "ARCHIVE_BASE_PATH": "/archive",\n        "SENDING_DOMAIN": "send.example.com",                      // \u2190 your sending hostname\n        "FROM_ADDRESS": "Newsletter <newsletter@send.example.com>" // \u2190 who your mail is from\n      }\n    }\n    ```\n\n    What each one does:\n\n    - **`routes`** puts the app on your hostname when you deploy. Cloudflare creates the DNS record and the certificate. Your domain must be in the same Cloudflare account, and the hostname can\'t already have a CNAME record; delete one if it does. The block also turns off the `workers.dev` addresses, so the app answers only on your hostname.\n    - **`PROVIDER` stays empty.** [Connect Amazon SES](04-ses.md) sets it. Until then the app runs without an email provider: posts can be written and previewed, but scheduling, test emails, and signups are refused. Never set it to `fake`, the top level\'s value, even when a wrangler warning suggests copying it: `fake` delivers nothing, and the app refuses it on your hostname.\n    - **`ARCHIVE_BASE_PATH`** is permanent once the first post goes out. Every post sent carries its `/archive/\u2026` link, and changing the prefix later breaks the links already mailed. Keep `/archive` unless you have a reason not to.\n    - **`FROM_ADDRESS`** is the address every email comes from. Keep it on your sending hostname, and set `SENDING_DOMAIN` to the part after the `@`.\n\n    Change every `example.com` value, the route included, even before you connect a provider. The app checks its settings but can\'t see the route: it refuses to run while `APP_ORIGIN`, `SENDING_DOMAIN`, or `FROM_ADDRESS`, or `ARCHIVE_ORIGIN` or `MEDIA_PUBLIC_BASE` if you set them, is still on `example.com`, since its links and the address your email comes from would name a domain that isn\'t yours.\n\n    Every other setting has a working default. [Configuration](../reference/01-configuration.md) lists them all, and what the app refuses.\n\n1. Check the file. This regenerates the binding types, and fails if the configuration doesn\'t parse:\n\n    ```bash\n    npm run typecheck\n    ```\n\n    Wrangler prints the binding types it generated and ends with a reminder to run it again whenever you change `wrangler.jsonc`. The type check that follows prints nothing when it passes.\n\n1. Commit your settings and push them to your repository. An upgrade changes only the release your instance runs, so your settings stay as they are:\n\n    ```bash\n    git commit -am "Configure production"\n    git push\n    ```\n\n## 5. Apply the schema\n\nCreate Kestrel\'s tables in the production 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. It applies only the ones the database hasn\'t seen, so running it again is harmless.\n\n## 6. Deploy\n\n```bash\nnpx wrangler deploy --env production\n```\n\nThis deploys the release your instance runs, with your settings. The output ends with the hostname the app now answers on. Deploying also registers the once-a-minute schedule that sends posts, which you can see under the Worker\'s **Triggers** tab in the Cloudflare dashboard.\n\n## Check it\n\n1. The app answers on your hostname. A new hostname can take a few minutes to get its certificate.\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\n1. The editor is locked. Until you set up Access in the next step, the app can\'t tell who is asking, so it lets no one in:\n\n    ```bash\n    curl -s -o /dev/null -w "%{http_code}\\n" https://newsletter.example.com/api/whoami\n    ```\n\n    ```\n    401\n    ```\n\n    In a browser, `https://newsletter.example.com/dashboard/` says the editor is locked until you set up Access. That\'s expected.\n\n1. In a browser, `https://newsletter.example.com/` shows the newsletter\'s public landing page. Its subscribe page, `/subscribe`, says signups aren\'t open yet, until Connect Amazon SES.\n\nIf the public pages instead say the newsletter is temporarily unavailable, and `/health` answers `500` with a body like `{"error":"invalid_config","variable":"APP_ORIGIN",\u2026}`, the setting it names is missing, malformed, or still on `example.com`. Fix it in `wrangler.jsonc`, commit, and deploy again.\n\nIf the public pages say the same, but `/health` answers `500` with `{"error":"schema_behind","missing":[\u2026],\u2026}`, the database hasn\'t run the migrations it lists, most often because step 5 was skipped or its prompt answered no. Run step 5\'s command, which the body\'s `message` repeats; the app answers as soon as it finishes, with no new deploy.\n\nNext, [lock the dashboard with Access](03-access.md).\n';
 
 // docs/get-started/03-access.md
-var access_default = '# Lock the dashboard with Access\n\nCloudflare Access puts a login in front of the editor and the API. Kestrel checks every request against that login as well, so a path left out of Access stays locked. The public pages readers see stay public.\n\nIn this guide, you set up Cloudflare Zero Trust, create one Access application that covers the editor and the API, and allow yourself in. Then you give the app two values from that application, and check that the login works.\n\n## 1. Set up Zero Trust\n\nAccess is part of Cloudflare Zero Trust. Your account needs a Zero Trust organization before it can create an Access application. Skip this section if your account already has one.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), select **Zero Trust**.\n\n1. Choose a team name. It becomes your team domain, `YOUR_TEAM.cloudflareaccess.com`, where your login page lives.\n\n1. Choose a plan. The Free plan covers a newsletter\'s editors. Cloudflare asks for payment details even on the Free plan, and doesn\'t charge them.\n\n## 2. Create the Access application\n\nThe editor lives under `/dashboard`, and the API under `/api`. One application covers both, so they share one login.\n\n1. In **Zero Trust**, go to **Access controls \u2192 Applications**, and select **Create new application**.\n\n1. Select **Self-hosted and private**.\n\n1. Select **Add public hostname**, and enter your app\'s hostname with the first path:\n\n    - **Subdomain:** `newsletter`\n    - **Domain:** `example.com`\n    - **Path:** `dashboard`\n\n1. Add a second public hostname with the same subdomain and domain, and the path `api`:\n\n    | Path | What it covers |\n    | --- | --- |\n    | `dashboard` | the editor |\n    | `api` | everything the editor and Claude read and change: posts, sends, subscribers, settings, and the in-app docs |\n\n    Each path covers everything under it. Leave every other path out. The landing page, the archive, subscribing, unsubscribing, images, and your email provider\'s webhooks must stay public.\n\n## 3. Allow yourself in\n\nEvery Access application denies everyone until a policy allows them.\n\n1. Under **Access policies**, create a new policy:\n\n    - **Policy name:** `Publishers`\n    - **Action:** Allow\n    - **Include:** the **Emails** selector, with your email address\n\n1. Keep the login method a new Zero Trust organization starts with: you sign in with your Cloudflare account. To sign in another way, such as a one-time code by email, add it under **Zero Trust \u2192 Integrations \u2192 Identity providers** first.\n\n1. Select **Create**.\n\n## 4. Give the app its two values\n\nThe app verifies each login against your team domain, and checks that it was issued for this application.\n\n1. Find your team domain under **Zero Trust \u2192 Settings**. It looks like `YOUR_TEAM.cloudflareaccess.com`.\n\n1. Find the application\'s audience tag. Under **Access controls \u2192 Applications**, select **Configure** on your application. On the **Additional settings** tab, copy the **Application Audience (AUD) Tag**.\n\n1. Store the team domain as a secret. The command prompts you for the value. Enter the hostname alone, without `https://`. If you paste it with `https://` or a trailing slash, the app drops them. Anything else that isn\'t a hostname is refused, naming `ACCESS_TEAM_DOMAIN`:\n\n    ```bash\n    npx wrangler secret put ACCESS_TEAM_DOMAIN --env production\n    ```\n\n1. Store the audience tag the same way:\n\n    ```bash\n    npx wrangler secret put ACCESS_AUD --env production\n    ```\n\n    A secret takes effect as soon as you store it, with no redeploy. The app needs both values. While only one is stored, it refuses its configuration and names the missing one: the editor says so, `/health` answers `500` with `"variable":"ACCESS_AUD"`, and the public pages say the newsletter is temporarily unavailable. Storing the second clears it.\n\n1. **(Optional, recommended)** Limit the editor to named people. The Access policy decides who can sign in. This list keeps that true if the policy is widened later, for another app or by mistake. Enter a comma-separated list of email addresses at the prompt:\n\n    ```bash\n    npx wrangler secret put ACCESS_ALLOWED_EMAILS --env production\n    ```\n\n    Without it, the app lets in anyone your Access policy allows.\n\n## Check it\n\n1. In a private browser window, open `https://newsletter.example.com/dashboard/`. Cloudflare asks you to sign in.\n\n1. Sign in. The editor loads, and its sidebar shows the email address you signed in with.\n\n1. In the same window, open `https://newsletter.example.com/api/whoami`. It shows you as a signed-in person, verified through Access:\n\n    ```\n    {"principal":{"kind":"human","email":"you@example.com"},"auth":{"mode":"access"}}\n    ```\n\n1. The public pages still need no login:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\nIf the editor says the configuration needs a fix, store the secret it names. If Cloudflare lets you in but the editor answers `401`, check the two secrets for a typo, or `ACCESS_ALLOWED_EMAILS` may leave out your address.\n\nNext, [connect Amazon SES](04-ses.md).\n';
+var access_default = '# Lock the dashboard with Access\n\nCloudflare Access puts a login in front of the editor and the API. Kestrel checks every request against that login as well, so a path left out of Access stays locked. The public pages readers see stay public.\n\nIn this guide, you set up Cloudflare Zero Trust, create one Access application that covers the editor and the API, and allow yourself in. Then you give the app two values from that application, and check that the login works.\n\n## 1. Set up Zero Trust\n\nAccess is part of Cloudflare Zero Trust. Your account needs a Zero Trust organization before it can create an Access application. Skip this section if your account already has one.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), select **Zero Trust**.\n\n1. Choose a team name. It becomes your team domain, `YOUR_TEAM.cloudflareaccess.com`, where your login page lives.\n\n1. Choose a plan. The Free plan covers a newsletter\'s editors. Cloudflare asks for payment details even on the Free plan, and doesn\'t charge them.\n\n## 2. Create the Access application\n\nThe editor lives under `/dashboard`, and the API under `/api`. One application covers both, so they share one login.\n\n1. In **Zero Trust**, go to **Access controls \u2192 Applications**, and select **Create new application**.\n\n1. Select **Self-hosted and private**.\n\n1. Select **Add public hostname**, and enter your app\'s hostname with the first path:\n\n    - **Subdomain:** `newsletter`\n    - **Domain:** `example.com`\n    - **Path:** `dashboard`\n\n1. Add a second public hostname with the same subdomain and domain, and the path `api`:\n\n    | Path | What it covers |\n    | --- | --- |\n    | `dashboard` | the editor |\n    | `api` | everything the editor and Claude read and change: posts, sends, subscribers, settings, and the in-app docs |\n\n    Each path covers everything under it. Leave every other path out. The landing page, the archive, subscribing, unsubscribing, images, and your email provider\'s webhooks must stay public.\n\n1. **(Optional)** Choose how long a sign-in lasts. The application\'s session duration defaults to 24 hours, so everyone signs in again each day. You can set anything from immediately to one month, as Cloudflare\'s [session management](https://developers.cloudflare.com/cloudflare-one/access-controls/access-settings/session-management/) describes. A longer session suits a publisher on their own computer, and a shorter one is safer on a shared one.\n\n## 3. Allow yourself in\n\nEvery Access application denies everyone until a policy allows them.\n\n1. Under **Access policies**, create a new policy:\n\n    - **Policy name:** `Publishers`\n    - **Action:** Allow\n    - **Include:** the **Emails** selector, with your email address\n\n1. Keep the login method a new Zero Trust organization starts with: you sign in with your Cloudflare account. To sign in another way, such as a one-time code by email, add it under **Zero Trust \u2192 Integrations \u2192 Identity providers** first.\n\n1. Select **Create**.\n\n## 4. Give the app its two values\n\nThe app verifies each login against your team domain, and checks that it was issued for this application.\n\n1. Find your team domain under **Zero Trust \u2192 Settings**. It looks like `YOUR_TEAM.cloudflareaccess.com`.\n\n1. Find the application\'s audience tag. Under **Access controls \u2192 Applications**, select **Configure** on your application. On the **Additional settings** tab, copy the **Application Audience (AUD) Tag**.\n\n1. Store the team domain as a secret. The command prompts you for the value. Enter the hostname alone, without `https://`. If you paste it with `https://` or a trailing slash, the app drops them. Anything else that isn\'t a hostname is refused, naming `ACCESS_TEAM_DOMAIN`:\n\n    ```bash\n    npx wrangler secret put ACCESS_TEAM_DOMAIN --env production\n    ```\n\n1. Store the audience tag the same way:\n\n    ```bash\n    npx wrangler secret put ACCESS_AUD --env production\n    ```\n\n    A secret takes effect as soon as you store it, with no redeploy. The app needs both values. While only one is stored, it refuses its configuration and names the missing one: the editor says so, `/health` answers `500` with `"variable":"ACCESS_AUD"`, and the public pages say the newsletter is temporarily unavailable. Storing the second clears it.\n\n1. **(Optional, recommended)** Limit the editor to named people. The Access policy decides who can sign in. This list keeps that true if the policy is widened later, for another app or by mistake. Enter a comma-separated list of email addresses at the prompt:\n\n    ```bash\n    npx wrangler secret put ACCESS_ALLOWED_EMAILS --env production\n    ```\n\n    Without it, the app lets in anyone your Access policy allows.\n\n## Check it\n\n1. In a private browser window, open `https://newsletter.example.com/dashboard/`. Cloudflare asks you to sign in.\n\n1. Sign in. The editor loads, and its sidebar shows the email address you signed in with.\n\n1. In the same window, open `https://newsletter.example.com/api/whoami`. It shows you as a signed-in person, verified through Access:\n\n    ```\n    {"principal":{"kind":"human","email":"you@example.com"},"auth":{"mode":"access"}}\n    ```\n\n1. The public pages still need no login:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\nIf the editor says the configuration needs a fix, store the secret it names. If Cloudflare lets you in but the editor answers `401`, check the two secrets for a typo, or `ACCESS_ALLOWED_EMAILS` may leave out your address.\n\nNext, [connect Amazon SES](04-ses.md).\n';
 
 // docs/get-started/04-ses.md
-var ses_default = '# Connect Amazon SES\n\nKestrel sends your posts through Amazon SES, Amazon\'s email service. SES only delivers the mail: Kestrel keeps your list, each subscriber\'s consent, and the record of every send. AWS reviews your account before it lets you send to anyone but yourself. This page asks for that early, and you test in the sandbox while you wait.\n\nIn this guide, you verify your sending hostname with SES and add a DMARC record. You forward readers\' replies to your inbox, and ask AWS for production access. You also route bounces and complaints to the app through SNS. Then you give the app its AWS credentials, set the provider, and deploy.\n\n## Before you begin\n\n- An [AWS account](https://portal.aws.amazon.com/billing/signup).\n\nTo move an instance that already sends through another provider or another SES account, read [Switch an instance that already sends](#switch-an-instance-that-already-sends) first.\n\n## 1. Verify your sending hostname\n\nSES sends only from an identity you\'ve verified. Verifying the whole hostname, rather than one address, lets any address on it send. It also sets up DKIM, which lets inboxes trust your mail.\n\n1. Open the [SES console](https://console.aws.amazon.com/ses/), and choose the region you send from in the menu at the top right. Any region that offers SES works, so pick one near you. A few newer regions must be [enabled for your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) before you can use them. SES keeps identities, quotas, and the sandbox separately in each region, so do every step in this one.\n\n1. Note the region\'s code. The menu shows a name, such as Europe (Ireland), but later steps need its code, such as `eu-west-1`. [Amazon SES endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html) lists each region\'s code beside its name. The MAIL FROM record, the SNS access policy, and `AWS_REGION` all use this one code.\n\n1. Under **Configuration**, choose **Identities**, then **Create identity**.\n\n1. Select **Domain**, and enter `send.example.com`. Keep the default DKIM settings: **Easy DKIM**, with a 2048-bit key. Choose **Create identity**.\n\n1. On the identity\'s **Authentication** tab, expand **Publish DNS records**. It lists three CNAME records.\n\n1. In the Cloudflare dashboard, add each record to your domain\'s DNS records, exactly as SES lists it. Set each one\'s proxy status to **DNS only**. Cloudflare adds your domain to the name, so a name ends in `._domainkey.send`.\n\n1. Wait until SES shows **DKIM configuration** as **Successful** and **Identity status** as **Verified**.\n\n## 2. Add a DMARC record\n\nDMARC tells inboxes what to do with mail that fails its checks, and sends you reports about it. SES doesn\'t add this record, so you add it yourself. It starts in monitor mode, which reports without blocking anything.\n\n1. In the Cloudflare dashboard, open your domain\'s DNS records, and add a record:\n\n    - **Type:** `TXT`\n    - **Name:** `_dmarc.send`\n    - **Content:** `v=DMARC1; p=none; rua=mailto:dmarc@example.com`\n\n1. Replace `dmarc@example.com` with an address that receives mail. Reports arrive there as attachments.\n\n[Sending-domain DNS](../reference/02-sending-domain-dns.md#dmarc-publish-a-policy-and-collect-reports) explains each record, and when to tighten DMARC.\n\n## 3. Receive replies at your From address\n\nWhen a reader replies to a post, or to their confirmation email, the reply goes to your From address, `newsletter@send.example.com`. Nothing receives mail there yet, so the reply bounces. Kestrel only sends mail, so you give the address an inbox yourself. Here you forward it to one you already read, with Cloudflare Email Routing, which is free on every plan.\n\n`send.example.com` receives no other mail, so turning on Email Routing there changes nothing else. Your SES records sit on other names under it. Inboxes check SES\'s mail for SPF at its return path, not here, so sending is unaffected.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Compute \u2192 Email Service \u2192 Email Routing**.\n\n1. Add `send.example.com` to Email Routing. Cloudflare adds subdomains from your domain\'s own settings: select `example.com`, then **Settings**, and add `send` under **Subdomains**.\n\n1. Cloudflare adds MX, SPF, and DKIM records for `send.example.com`, and locks them. Wait until they show as added.\n\n1. Under **Destination Addresses**, add the inbox you want replies in. Open the email Cloudflare sends to it, and select **Verify email address**. An address you\'ve already verified with Cloudflare, such as one for [notifications](../guides/03-notifications.md), is listed already.\n\n1. Under **Routing Rules**, select **Create routing rule**. For **Email pattern**, enter `newsletter`, the part of your From address before the `@`, and select `send.example.com`. Set **Action** to **Send to an email**, select your inbox as the **Destination**, and save.\n\nOn a subdomain, Email Routing forwards only the addresses you add a rule for, with no catch-all. That\'s all a From address needs.\n\n- **Automatic replies arrive too.** Out-of-office and other automatic replies go to your From address, so they reach your inbox. Bounces don\'t: they go to SES\'s return path, and the app handles them as before.\n- **Your DMARC reports need an inbox too.** Your DMARC record\'s report address may not receive mail. If so, change the record\'s `rua` to `mailto:dmarc@send.example.com`, and add a second rule that forwards `dmarc` the same way.\n- **Your answers come from your inbox.** A forwarded reply comes from the reader\'s own address. When you answer it, your answer goes out from the inbox it was forwarded to, not from `newsletter@send.example.com`.\n\nTo answer from the newsletter\'s own address, give it a real mailbox instead of forwarding it. Point `send.example.com`\'s MX records at a mail host you use, such as [Fastmail](https://www.fastmail.help/hc/en-us/articles/360060591133) or [Google Workspace](https://support.google.com/a/answer/140034). Then create `newsletter@send.example.com` there, as the host\'s docs describe. If you send from it, the host\'s SPF and DKIM records go on `send.example.com` beside SES\'s. SES\'s mail is unaffected, since its SPF is checked at its return path. And if your From address is on a domain that already receives mail, replies already reach it, and you can skip this section.\n\nSome replies ask you to do something, and Kestrel can\'t see them, so acting on them is yours. In the editor, open **Subscribers**, and use the reader\'s row menu. Choose **Unsubscribe** for a reader who asks to leave, and **Erase** for one who asks you to delete their data. A reader who never confirmed isn\'t mailed, so their row offers only **Erase**.\n\n## 4. (Optional) Set a custom MAIL FROM domain\n\nSES sends with its own return path by default, so SPF passes for `amazonses.com` rather than for your hostname. DMARC still passes, through DKIM. A custom MAIL FROM domain makes SPF pass for your hostname too, a second check in your favor.\n\n1. In SES, open the `send.example.com` identity. Under **Custom MAIL FROM domain**, choose **Edit**.\n\n1. Select **Use a custom MAIL FROM domain**, and enter `bounce.send.example.com`. For **Behavior on MX failure**, keep **Use default MAIL FROM domain**. Choose **Save changes**.\n\n1. In Cloudflare, add the two records SES lists. Replace `us-east-1` with your region\'s code from section 1:\n\n    - **Type:** `MX`, **Name:** `bounce.send`, **Mail server:** `feedback-smtp.us-east-1.amazonses.com`, **Priority:** `10`\n    - **Type:** `TXT`, **Name:** `bounce.send`, **Content:** `v=spf1 include:amazonses.com ~all`\n\n1. Wait until SES shows the MAIL FROM domain as **Successful**.\n\n## 5. Request production access\n\nA new SES account starts in the sandbox. It sends only to addresses you\'ve verified in SES, up to 200 emails a day and one a second. Ask AWS to lift those limits now, and test while you wait.\n\n1. Name your publication first, since AWS may visit your website to review the request. In the editor, open **Settings \u2192 Publication identity**, and enter the name and tagline. Until you do, your public pages show the name in your From address. The subscribe form stays closed until section 8 sets the provider.\n\n1. In SES, open the **Account dashboard**, select **View Get set up page**, and then **Request production access**.\n\n1. Fill in the request:\n\n    - **Mail type:** Marketing\n    - **Website URL:** `https://newsletter.example.com/`\n\n1. Check the acknowledgement, and select **Submit request**. AWS Support answers by email, and may ask how you collect addresses and handle bounces.\n\n1. While you wait, verify the two addresses you test with in [Verify it works](05-verify.md#before-you-begin), so the sandbox lets you mail them. For each, under **Identities**, choose **Create identity**, select **Email address**, and follow the link in the email AWS sends.\n\nIf AWS asks for more detail, reply in the support case. If it denies the request, reply there, or open a new request from the **Account dashboard**. Either way, say how Kestrel handles your list:\n\n- Signups use double opt-in: each subscriber confirms by email before joining the list.\n- Every post offers one-click unsubscribe.\n- Bounces and complaints reach the app through SNS, and it stops mailing those addresses automatically.\n- How many subscribers you expect, and how often you send.\n\nYour account stays in the sandbox until AWS grants access, so don\'t go live before then. In the sandbox, a signup from any address you haven\'t verified fails, and a post reaches only your verified addresses.\n\nWhen AWS grants access, the **Account dashboard** shows your daily quota and your maximum send rate. You set the rate in the app in section 8. The rate decides how fast a send goes out, and [As your list grows](06-go-live.md#as-your-list-grows) says when to ask AWS to raise it.\n\n## 6. Send bounces and complaints to SNS\n\nSES reports what happens to each email through SNS, the AWS notification service. A configuration set says which events to report, and an SNS topic carries them to the app.\n\n1. In SES, under **Configuration**, choose **Configuration sets**, then **Create set**. Name it `kestrel-mail`, and choose **Create set**.\n\n1. On the set\'s **Event destinations** tab, choose **Add destination**. Select **Hard bounces**, **Complaints**, **Deliveries**, and **Rendering failures**, and choose **Next**. A rendering failure is an email SES took but couldn\'t build. It shouldn\'t happen, and the app logs it as an error if it does.\n\n1. For **Destination type**, select **Amazon SNS**. Name it `kestrel-sns`, and keep **Event publishing** enabled. Choose **Next**.\n\n1. For **SNS topic**, choose **Create SNS topic**. Make it a **Standard** topic named `kestrel-events`. Choose **Next**, then **Add destination**.\n\n1. Make the set your hostname\'s default, so SES reports on every email sent from it. Open the `send.example.com` identity, and choose the **Configuration set** tab. Under **Default configuration set**, choose **Edit**, select `kestrel-mail`, and save.\n\n1. Open the topic in the [SNS console](https://console.aws.amazon.com/sns/), and copy its ARN. It looks like `arn:aws:sns:us-east-1:111122223333:kestrel-events`. After `sns` comes your region\'s code, then your 12-digit account ID. The account menu at the top right of the console also shows the account ID.\n\n1. Let SES publish to the topic. Choose **Edit**, expand **Access policy**, and add this statement to the `Statement` list:\n\n    ```json\n    {\n      "Effect": "Allow",\n      "Principal": { "Service": "ses.amazonaws.com" },\n      "Action": "sns:Publish",\n      "Resource": "REPLACE_WITH_TOPIC_ARN",\n      "Condition": {\n        "StringEquals": {\n          "AWS:SourceAccount": "REPLACE_WITH_ACCOUNT_ID",\n          "AWS:SourceArn": "arn:aws:ses:us-east-1:REPLACE_WITH_ACCOUNT_ID:configuration-set/kestrel-mail"\n        }\n      }\n    }\n    ```\n\n    Replace the topic ARN, and both copies of the account ID, with the values from your ARN. Replace `us-east-1` with your region\'s code, the same one the ARN shows. Choose **Save changes**.\n\nYou subscribe the app to the topic in section 9, once it runs on SES.\n\n## 7. Create the app\'s AWS key\n\nThe app sends through an IAM user whose key can only send email. That limits the harm if the key ever leaks.\n\n1. In the [IAM console](https://console.aws.amazon.com/iam/), go to **Users**, and choose **Create user**. Name it `kestrel-sender`, and leave console access off.\n\n1. When asked for permissions, choose **Attach policies directly**, then **Create policy**. The policy editor opens in a new browser tab.\n\n1. In the new tab, choose the **JSON** editor, and replace its contents with this policy:\n\n    ```json\n    {\n      "Version": "2012-10-17",\n      "Statement": [\n        {\n          "Effect": "Allow",\n          "Action": ["ses:SendEmail", "ses:SendBulkEmail"],\n          "Resource": "*"\n        }\n      ]\n    }\n    ```\n\n    Choose **Next**, name the policy `kestrel-send-email`, and choose **Create policy**. You can close this tab.\n\n1. Go back to the first tab, where you\'re creating the user. Refresh the policy list, search for `kestrel-send-email`, and select it.\n\n1. Choose **Next**, then **Create user**.\n\n1. Open the user, and on the **Security credentials** tab, choose **Create access key**. For the use case, choose **Application running outside AWS**.\n\n1. Copy the access key ID and the secret access key. AWS shows the secret only once.\n\n## 8. Set the provider and deploy\n\nUntil now the app has run with no email provider connected, refusing to send. Setting `PROVIDER` connects SES. Store the secrets before you set it. With `PROVIDER` set to `ses` and a required secret missing, the app refuses to run, and sends nothing, until you store it. `/health` and the editor\'s **A setting needs fixing** page name the missing secret, and reader pages say the newsletter is temporarily unavailable. `SES_CONFIGURATION_SET` is the one optional secret.\n\n1. Store the access key ID, and paste it at the prompt:\n\n    ```bash\n    npx wrangler secret put AWS_ACCESS_KEY_ID --env production\n    ```\n\n1. Store the secret access key:\n\n    ```bash\n    npx wrangler secret put AWS_SECRET_ACCESS_KEY --env production\n    ```\n\n1. Store the topic ARN from section 6. The app accepts events only from this topic:\n\n    ```bash\n    npx wrangler secret put SNS_TOPIC_ARN --env production\n    ```\n\n1. Store the configuration set\'s name, `kestrel-mail`. It\'s optional but recommended: the app names it on every email, so SES reports on each one even without the default. Type it exactly as the set is named in this region: if SES can\'t find the set, it refuses every email, and a list send is held until the name is fixed or the set created:\n\n    ```bash\n    npx wrangler secret put SES_CONFIGURATION_SET --env production\n    ```\n\n1. In `wrangler.jsonc`, edit the `production` block\'s `vars`. Change `PROVIDER` to `ses` (it\'s `""` on a new instance; add it if your block has none), and add `SES_MAX_SEND_RATE`. Change `AWS_REGION` to your region\'s code from section 1. Your other values stay as they are. The block ends up like this:\n\n    ```jsonc\n    "vars": {\n      "PROVIDER": "ses",             // \u2190 set to ses\n      "APP_ORIGIN": "https://newsletter.example.com",\n      "ARCHIVE_BASE_PATH": "/archive",\n      "SENDING_DOMAIN": "send.example.com",\n      "FROM_ADDRESS": "Newsletter <newsletter@send.example.com>",\n      "AWS_REGION": "us-east-1",     // \u2190 change: your region\'s code\n      "SES_MAX_SEND_RATE": "1"       // \u2190 new: your maximum send rate; 1 in the sandbox\n    }\n    ```\n\n    On Workers Paid, also add `"SUBREQUEST_BUDGET": "10000"`, the plan\'s limit, so each minute sends more. Leave it out on Workers Free. [As your list grows](06-go-live.md#as-your-list-grows) says when the plan is worth it.\n\n    When AWS grants production access, set `SES_MAX_SEND_RATE` to the maximum send rate on the **Account dashboard**, and deploy again. The app keeps to that rate, so SES doesn\'t throttle your send.\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am "Send through Amazon SES"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\n## 9. Subscribe the app to the topic\n\nSNS delivers events only to a subscriber that has confirmed. The app confirms on its own, once it checks that the request came from your topic.\n\n1. In the SNS console, open your topic, and choose **Create subscription**.\n\n1. Set **Protocol** to **HTTPS**, and enter the endpoint:\n\n    ```\n    https://newsletter.example.com/webhooks/ses\n    ```\n\n1. Leave raw message delivery off, and choose **Create subscription**.\n\n1. Reload the subscription. Its status changes to **Confirmed**, with nothing for you to click.\n\nIf it stays **Pending confirmation**, the request never reached the app, or the app refused it. Check, in this order:\n\n- **Access covers `/webhooks/ses`.** If your Access application covers more than `/dashboard` and `/api`, SNS gets the login page instead of the app. Remove that path from your Access application, so only `dashboard` and `api` remain.\n- **`SNS_TOPIC_ARN` matches the topic\'s ARN.**\n- **The deploy in section 8 finished.**\n\nOnce you\'ve fixed the cause, select the subscription, and choose **Request confirmation**. SNS sends the request again, and the app confirms it. SNS doesn\'t let you delete a subscription while it\'s pending, and removes it on its own after 48 hours.\n\n## Switch an instance that already sends\n\nChange `PROVIDER`, or move to another account with the same provider, only while no send is sending. The dashboard lists any send in progress.\n\nWhen a request to a provider gets no answer, Kestrel can\'t know whether its recipients were mailed. Moving to SES, from another provider or another SES account, mails none of them twice. Kestrel never repeats an unanswered request to SES, so those recipients wait for you to decide whether they were mailed. Use **Resolve** on the send\'s page.\n\nKestrel can\'t tell whether those emails went out. SES\'s console shows sent messages only if you\'ve turned on Virtual Deliverability Manager, which this guide doesn\'t set up. So **Assume not sent** is the safe default. Those readers may miss this post, but they get your next one. No one is mailed twice. Choose **Assume sent** only when you know otherwise, such as a reader who says they got it.\n\n## Check it\n\n1. The app answers on your hostname:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\n1. The webhook is public, and refuses a request that isn\'t from SNS:\n\n    ```bash\n    curl -s -o /dev/null -w "%{http_code}\\n" -X POST https://newsletter.example.com/webhooks/ses\n    ```\n\n    ```\n    400\n    ```\n\n    Any other answer, such as a redirect to your Cloudflare login, means Access covers the webhook. Remove that path from your Access application.\n\n1. The SNS subscription shows **Confirmed**.\n\n1. Your From address has somewhere to go. In Cloudflare, your domain\'s DNS records show the ones Email Routing added for `send`, beside section 1\'s DKIM records:\n\n    - **Type:** `MX`, **Name:** `send`, three of them, for `route1.mx.cloudflare.net`, `route2.mx.cloudflare.net`, and `route3.mx.cloudflare.net`\n    - **Type:** `TXT`, **Name:** `send`, **Content:** `v=spf1 include:_spf.mx.cloudflare.net ~all`\n    - **Type:** `TXT`, **Name:** `cf2024-1._domainkey.send`, Cloudflare\'s DKIM key\n\n    The world sees the MX records too:\n\n    ```bash\n    dig +short MX send.example.com\n    ```\n\n    It lists the three `route` servers. Email Routing\'s **Routing Rules** shows your rule for `newsletter@send.example.com`, and **Destination Addresses** shows your inbox as verified. A reply to your test email in the next step proves the forwarding works.\n\n1. In the editor, **Settings \u2192 Email sender** shows Amazon SES and your From address, where it said **No email provider connected** before.\n\n1. In a browser, `https://newsletter.example.com/subscribe` shows the subscribe form, where it said signups aren\'t open yet.\n\nThe test sends in the next step prove the rest. In the sandbox, send them only to the addresses you verified in section 5, and to the SES test addresses that page lists.\n\nSES charges for each email it sends, test emails included. [Amazon SES pricing](https://aws.amazon.com/ses/pricing/) lists the rates.\n\nNext, [verify it works](05-verify.md).\n';
+var ses_default = '# Connect Amazon SES\n\nKestrel sends the newsletter\'s posts through Amazon SES, Amazon\'s email service. SES only delivers the mail: Kestrel keeps the list, each subscriber\'s consent, and the record of every send. AWS reviews your account before it lets you send to anyone but yourself. This page asks for that early, and you test in the sandbox while you wait.\n\nIn this guide, you verify your sending hostname with SES and add a DMARC record. You forward readers\' replies to the publisher\'s inbox, and ask AWS for production access. You also route bounces and complaints to the app through SNS. Then you give the app its AWS credentials, set the provider, and deploy.\n\n## Before you begin\n\n- An [AWS account](https://portal.aws.amazon.com/billing/signup).\n\nTo move an instance that already sends through another provider or another SES account, read [Switch an instance that already sends](#switch-an-instance-that-already-sends) first.\n\n## 1. Verify your sending hostname\n\nSES sends only from an identity you\'ve verified. Verifying the whole hostname, rather than one address, lets any address on it send. It also sets up DKIM, which lets inboxes trust your mail.\n\n1. Open the [SES console](https://console.aws.amazon.com/ses/), and choose the region you send from in the menu at the top right. Any region that offers SES works, so pick one near you. A few newer regions must be [enabled for your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) before you can use them. SES keeps identities, quotas, and the sandbox separately in each region, so do every step in this one.\n\n1. Note the region\'s code. The menu shows a name, such as Europe (Ireland), but later steps need its code, such as `eu-west-1`. [Amazon SES endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html) lists each region\'s code beside its name. The MAIL FROM record, the SNS access policy, and `AWS_REGION` all use this one code.\n\n1. Under **Configuration**, choose **Identities**, then **Create identity**.\n\n1. Select **Domain**, and enter `send.example.com`. Keep the default DKIM settings: **Easy DKIM**, with a 2048-bit key. Choose **Create identity**.\n\n1. On the identity\'s **Authentication** tab, expand **Publish DNS records**. It lists three CNAME records.\n\n1. In the Cloudflare dashboard, add each record to your domain\'s DNS records, exactly as SES lists it. Set each one\'s proxy status to **DNS only**. Cloudflare adds your domain to the name, so a name ends in `._domainkey.send`.\n\n1. Wait until SES shows **DKIM configuration** as **Successful** and **Identity status** as **Verified**.\n\n## 2. Add a DMARC record\n\nDMARC tells inboxes what to do with mail that fails its checks, and sends you reports about it. SES doesn\'t add this record, so you add it yourself. It starts in monitor mode, which reports without blocking anything.\n\n1. In the Cloudflare dashboard, open your domain\'s DNS records, and add a record:\n\n    - **Type:** `TXT`\n    - **Name:** `_dmarc.send`\n    - **Content:** `v=DMARC1; p=none; rua=mailto:dmarc@example.com`\n\n1. Replace `dmarc@example.com` with an address that receives mail. Reports arrive there as attachments.\n\n[Sending-domain DNS](../reference/02-sending-domain-dns.md#dmarc-publish-a-policy-and-collect-reports) explains each record, and when to tighten DMARC.\n\n## 3. Receive replies at your From address\n\nWhen a reader replies to a post, or to their confirmation email, the reply goes to your From address, `newsletter@send.example.com`. Nothing receives mail there yet, so the reply bounces. Kestrel only sends mail, so you give the address an inbox yourself. Here you forward it to the publisher\'s inbox, with Cloudflare Email Routing, which is free on every plan. The publisher is whoever writes and sends the newsletter, which may be you.\n\n`send.example.com` receives no other mail, so turning on Email Routing there changes nothing else. Your SES records sit on other names under it. Inboxes check SES\'s mail for SPF at its return path, not here, so sending is unaffected.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Compute \u2192 Email Service \u2192 Email Routing**.\n\n1. Add `send.example.com` to Email Routing. Cloudflare adds subdomains from your domain\'s own settings: select `example.com`, then **Settings**, and add `send` under **Subdomains**.\n\n1. Cloudflare adds MX, SPF, and DKIM records for `send.example.com`, and locks them. Wait until they show as added.\n\n1. Under **Destination Addresses**, add the publisher\'s inbox. Open the email Cloudflare sends to it, and select **Verify email address**. If it isn\'t your inbox, ask the publisher to do this step. An address you\'ve already verified with Cloudflare, such as one for [notifications](../guides/03-notifications.md), is listed already.\n\n1. Under **Routing Rules**, select **Create routing rule**. For **Email pattern**, enter `newsletter`, the part of your From address before the `@`, and select `send.example.com`. Set **Action** to **Send to an email**, select the publisher\'s inbox as the **Destination**, and save.\n\nOn a subdomain, Email Routing forwards only the addresses you add a rule for, with no catch-all. That\'s all a From address needs.\n\n- **Automatic replies arrive too.** Out-of-office and other automatic replies go to your From address, so they reach the publisher\'s inbox. Bounces don\'t: they go to SES\'s return path, and the app handles them as before.\n- **Your DMARC reports need an inbox too.** Your DMARC record\'s report address may not receive mail. If so, change the record\'s `rua` to `mailto:dmarc@send.example.com`, and add a second rule that forwards `dmarc` the same way.\n- **Answers come from the publisher\'s inbox.** A forwarded reply comes from the reader\'s own address. An answer to it goes out from the inbox it was forwarded to, not from `newsletter@send.example.com`.\n\nTo answer from the newsletter\'s own address, give it a real mailbox instead of forwarding it. Point `send.example.com`\'s MX records at a mail host you use, such as [Fastmail](https://www.fastmail.help/hc/en-us/articles/360060591133) or [Google Workspace](https://support.google.com/a/answer/140034). Then create `newsletter@send.example.com` there, as the host\'s docs describe. If you send from it, the host\'s SPF and DKIM records go on `send.example.com` beside SES\'s. SES\'s mail is unaffected, since its SPF is checked at its return path. And if your From address is on a domain that already receives mail, replies already reach it, and you can skip this section.\n\nSome replies ask the publisher to do something, and Kestrel can\'t see them, so the publisher acts on them, as [Sending rules](../publishing/02-sending-rules.md#when-a-reader-asks-to-leave-or-to-be-deleted) describes.\n\n## 4. (Optional) Set a custom MAIL FROM domain\n\nSES sends with its own return path by default, so SPF passes for `amazonses.com` rather than for your hostname. DMARC still passes, through DKIM. A custom MAIL FROM domain makes SPF pass for your hostname too, a second check in your favor.\n\n1. In SES, open the `send.example.com` identity. Under **Custom MAIL FROM domain**, choose **Edit**.\n\n1. Select **Use a custom MAIL FROM domain**, and enter `bounce.send.example.com`. For **Behavior on MX failure**, keep **Use default MAIL FROM domain**. Choose **Save changes**.\n\n1. In Cloudflare, add the two records SES lists. Replace `us-east-1` with your region\'s code from section 1:\n\n    - **Type:** `MX`, **Name:** `bounce.send`, **Mail server:** `feedback-smtp.us-east-1.amazonses.com`, **Priority:** `10`\n    - **Type:** `TXT`, **Name:** `bounce.send`, **Content:** `v=spf1 include:amazonses.com ~all`\n\n1. Wait until SES shows the MAIL FROM domain as **Successful**.\n\n## 5. Request production access\n\nA new SES account starts in the sandbox. It sends only to addresses you\'ve verified in SES, up to 200 emails a day and one a second. Ask AWS to lift those limits now, and test while you wait.\n\n1. Name the publication first, or ask the publisher for its name, since AWS may visit its website to review the request. In the editor, open **Settings \u2192 Publication identity**, and enter the name and tagline. Until then, the public pages show the name in your From address. The subscribe form stays closed until section 8 sets the provider.\n\n1. In SES, open the **Account dashboard**, select **View Get set up page**, and then **Request production access**.\n\n1. Fill in the request:\n\n    - **Mail type:** Marketing\n    - **Website URL:** `https://newsletter.example.com/`\n\n1. Check the acknowledgement, and select **Submit request**. AWS Support answers by email, and may ask how you collect addresses and handle bounces.\n\n1. While you wait, verify the two addresses you test with in [Verify it works](05-verify.md#before-you-begin), so the sandbox lets you mail them. For each, under **Identities**, choose **Create identity**, select **Email address**, and follow the link in the email AWS sends.\n\nIf AWS asks for more detail, reply in the support case. If it denies the request, reply there, or open a new request from the **Account dashboard**. Either way, say how Kestrel handles the list:\n\n- Signups use double opt-in: each subscriber confirms by email before joining the list.\n- Every post offers one-click unsubscribe.\n- Bounces and complaints reach the app through SNS, and it stops mailing those addresses automatically.\n- How many subscribers the newsletter expects, and how often it sends.\n\nYour account stays in the sandbox until AWS grants access, so don\'t go live before then. In the sandbox, SES refuses mail to any address you haven\'t verified:\n\n- A signup from an unverified address gets no confirmation email. The app emails the publisher about it, at most once a day.\n- A post goes to your verified addresses and then waits, with the line "The provider is refusing the account" and SES\'s words. No reader is marked unsent. Once AWS grants access, the post goes to the rest at its next retry, mailing no one twice.\n- A daily quota refusal in the sandbox (200 emails a day) means the same thing: request production access rather than a higher quota.\n\nWhen AWS grants access, the **Account dashboard** shows your daily quota and your maximum send rate. You set the rate in the app in section 8. The rate decides how fast a send goes out, and [As your list grows](../guides/09-as-your-list-grows.md) says when to ask AWS to raise it.\n\n## 6. Send bounces and complaints to SNS\n\nSES reports what happens to each email through SNS, the AWS notification service. A configuration set says which events to report, and an SNS topic carries them to the app.\n\n1. In SES, under **Configuration**, choose **Configuration sets**, then **Create set**. Name it `kestrel-mail`, and choose **Create set**.\n\n1. On the set\'s **Event destinations** tab, choose **Add destination**. Select **Hard bounces**, **Complaints**, **Deliveries**, and **Rendering failures**, and choose **Next**. A rendering failure is an email SES took but couldn\'t build. It shouldn\'t happen, and the app logs it as an error if it does.\n\n1. For **Destination type**, select **Amazon SNS**. Name it `kestrel-sns`, and keep **Event publishing** enabled. Choose **Next**.\n\n1. For **SNS topic**, choose **Create SNS topic**. Make it a **Standard** topic named `kestrel-events`. Choose **Next**, then **Add destination**.\n\n1. Make the set your hostname\'s default, so SES reports on every email sent from it. Open the `send.example.com` identity, and choose the **Configuration set** tab. Under **Default configuration set**, choose **Edit**, select `kestrel-mail`, and save.\n\n1. Open the topic in the [SNS console](https://console.aws.amazon.com/sns/), and copy its ARN. It looks like `arn:aws:sns:us-east-1:111122223333:kestrel-events`. After `sns` comes your region\'s code, then your 12-digit account ID. The account menu at the top right of the console also shows the account ID.\n\n1. Let SES publish to the topic. Choose **Edit**, expand **Access policy**, and add this statement to the `Statement` list:\n\n    ```json\n    {\n      "Effect": "Allow",\n      "Principal": { "Service": "ses.amazonaws.com" },\n      "Action": "sns:Publish",\n      "Resource": "REPLACE_WITH_TOPIC_ARN",\n      "Condition": {\n        "StringEquals": {\n          "AWS:SourceAccount": "REPLACE_WITH_ACCOUNT_ID",\n          "AWS:SourceArn": "arn:aws:ses:us-east-1:REPLACE_WITH_ACCOUNT_ID:configuration-set/kestrel-mail"\n        }\n      }\n    }\n    ```\n\n    Replace the topic ARN, and both copies of the account ID, with the values from your ARN. Replace `us-east-1` with your region\'s code, the same one the ARN shows. Choose **Save changes**.\n\nYou subscribe the app to the topic in section 9, once it runs on SES.\n\n## 7. Create the app\'s AWS key\n\nThe app sends through an IAM user whose key can only send email. That limits the harm if the key ever leaks.\n\n1. In the [IAM console](https://console.aws.amazon.com/iam/), go to **Users**, and choose **Create user**. Name it `kestrel-sender`, and leave console access off.\n\n1. When asked for permissions, choose **Attach policies directly**, then **Create policy**. The policy editor opens in a new browser tab.\n\n1. In the new tab, choose the **JSON** editor, and replace its contents with this policy:\n\n    ```json\n    {\n      "Version": "2012-10-17",\n      "Statement": [\n        {\n          "Effect": "Allow",\n          "Action": ["ses:SendEmail", "ses:SendBulkEmail"],\n          "Resource": "*"\n        }\n      ]\n    }\n    ```\n\n    Choose **Next**, name the policy `kestrel-send-email`, and choose **Create policy**. You can close this tab.\n\n1. Go back to the first tab, where you\'re creating the user. Refresh the policy list, search for `kestrel-send-email`, and select it.\n\n1. Choose **Next**, then **Create user**.\n\n1. Open the user, and on the **Security credentials** tab, choose **Create access key**. For the use case, choose **Application running outside AWS**.\n\n1. Copy the access key ID and the secret access key. AWS shows the secret only once.\n\n## 8. Set the provider and deploy\n\nUntil now the app has run with no email provider connected, refusing to send. Setting `PROVIDER` connects SES. Store the secrets before you set it. With `PROVIDER` set to `ses` and a required secret missing, the app refuses to run, and sends nothing, until you store it. `/health` and the editor\'s **A setting needs fixing** page name the missing secret, and reader pages say the newsletter is temporarily unavailable. `SES_CONFIGURATION_SET` is the one optional secret.\n\n1. Store the access key ID, and paste it at the prompt:\n\n    ```bash\n    npx wrangler secret put AWS_ACCESS_KEY_ID --env production\n    ```\n\n1. Store the secret access key:\n\n    ```bash\n    npx wrangler secret put AWS_SECRET_ACCESS_KEY --env production\n    ```\n\n1. Store the topic ARN from section 6. The app accepts events only from this topic:\n\n    ```bash\n    npx wrangler secret put SNS_TOPIC_ARN --env production\n    ```\n\n1. Store the configuration set\'s name, `kestrel-mail`. It\'s optional but recommended: the app names it on every email, so SES reports on each one even without the default. Type it exactly as the set is named in this region: if SES can\'t find the set, it refuses every email, and a list send is held until the name is fixed or the set created:\n\n    ```bash\n    npx wrangler secret put SES_CONFIGURATION_SET --env production\n    ```\n\n1. In `wrangler.jsonc`, edit the `production` block\'s `vars`. Change `PROVIDER` to `ses` (it\'s `""` on a new instance; add it if your block has none), and add `SES_MAX_SEND_RATE`. Change `AWS_REGION` to your region\'s code from section 1. Your other values stay as they are. The block ends up like this:\n\n    ```jsonc\n    "vars": {\n      "PROVIDER": "ses",             // \u2190 set to ses\n      "APP_ORIGIN": "https://newsletter.example.com",\n      "ARCHIVE_BASE_PATH": "/archive",\n      "SENDING_DOMAIN": "send.example.com",\n      "FROM_ADDRESS": "Newsletter <newsletter@send.example.com>",\n      "AWS_REGION": "us-east-1",     // \u2190 change: your region\'s code\n      "SES_MAX_SEND_RATE": "1"       // \u2190 new: your maximum send rate; 1 in the sandbox\n    }\n    ```\n\n    On Workers Paid, also add `"SUBREQUEST_BUDGET": "10000"`, the plan\'s limit, so each minute sends more. Leave it out on Workers Free. [As your list grows](../guides/09-as-your-list-grows.md) says when the plan is worth it.\n\n    When AWS grants production access, set `SES_MAX_SEND_RATE` to the maximum send rate on the **Account dashboard**, and deploy again. The app keeps to that rate, so SES doesn\'t throttle your send.\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am "Send through Amazon SES"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\n## 9. Subscribe the app to the topic\n\nSNS delivers events only to a subscriber that has confirmed. The app confirms on its own, once it checks that the request came from your topic.\n\n1. In the SNS console, open your topic, and choose **Create subscription**.\n\n1. Set **Protocol** to **HTTPS**, and enter the endpoint:\n\n    ```\n    https://newsletter.example.com/webhooks/ses\n    ```\n\n1. Leave raw message delivery off, and choose **Create subscription**.\n\n1. Reload the subscription. Its status changes to **Confirmed**, with nothing for you to click.\n\n1. Give SNS longer to retry. By default it retries a failed delivery 3 times over about a minute, then discards the event, so a bounce that arrives while the app is briefly down or mid-deploy is lost, and the address gets your next post. Open the topic, choose **Edit**, and expand **Delivery policy (HTTP/S)**. Clear **Use the default delivery policy**, set these, and choose **Save changes**:\n\n    | Field | Value |\n    | --- | --- |\n    | Number of retries | `13` |\n    | Retries without delay | `0` |\n    | Minimum delay | `20` |\n    | Minimum delay retries | `2` |\n    | Maximum delay | `300` |\n    | Maximum delay retries | `6` |\n    | Retry-backoff function | Exponential |\n\n    SNS then keeps trying for most of an hour, the longest it allows. It never retries an event the app refused. The app refuses only an event it can\'t verify came from your topic, and logs an error when one claims to be from SNS.\n\n1. **(Optional)** Keep what SNS still can\'t deliver. On the subscription, choose **Edit**, and set a **Redrive policy (dead-letter queue)** to an SQS queue of your own. SNS then moves an event there instead of discarding it, where you can read it later. [Amazon SNS dead-letter queues](https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html) covers the queue and its permissions.\n\nIf it stays **Pending confirmation**, the request never reached the app, or the app refused it. Check, in this order:\n\n- **Access covers `/webhooks/ses`.** If your Access application covers more than `/dashboard` and `/api`, SNS gets the login page instead of the app. Remove that path from your Access application, so only `dashboard` and `api` remain.\n- **`SNS_TOPIC_ARN` matches the topic\'s ARN.** If it doesn\'t, the app\'s logs show a `webhook.refused` error naming both.\n- **The deploy in section 8 finished.**\n\nOnce you\'ve fixed the cause, select the subscription, and choose **Request confirmation**. SNS sends the request again, and the app confirms it. SNS doesn\'t let you delete a subscription while it\'s pending, and removes it on its own after 48 hours.\n\n## Switch an instance that already sends\n\nChange `PROVIDER`, or move to another account with the same provider, only while no send is sending. The dashboard lists any send in progress.\n\nWhen a request to a provider gets no answer, Kestrel can\'t know whether its recipients were mailed. Moving to SES, from another provider or another SES account, mails none of them twice. Kestrel never repeats an unanswered request to SES, so those recipients wait for you to decide whether they were mailed. Use **Resolve** on the send\'s page.\n\nKestrel can\'t tell whether those emails went out. SES\'s console shows sent messages only if you\'ve turned on Virtual Deliverability Manager, which this guide doesn\'t set up. So **Assume not sent** is the safe default. Those readers may miss this post, but they get your next one. No one is mailed twice. Choose **Assume sent** only when you know otherwise, such as a reader who says they got it.\n\n## Check it\n\n1. The app answers on your hostname:\n\n    ```bash\n    curl https://newsletter.example.com/health\n    ```\n\n    ```\n    {"status":"ok","service":"kestrel"}\n    ```\n\n1. The webhook is public, and refuses a request that isn\'t from SNS:\n\n    ```bash\n    curl -s -o /dev/null -w "%{http_code}\\n" -X POST https://newsletter.example.com/webhooks/ses\n    ```\n\n    ```\n    400\n    ```\n\n    Any other answer, such as a redirect to your Cloudflare login, means Access covers the webhook. Remove that path from your Access application.\n\n1. The SNS subscription shows **Confirmed**.\n\n1. Your From address has somewhere to go. In Cloudflare, your domain\'s DNS records show the ones Email Routing added for `send`, beside section 1\'s DKIM records:\n\n    - **Type:** `MX`, **Name:** `send`, three of them, for `route1.mx.cloudflare.net`, `route2.mx.cloudflare.net`, and `route3.mx.cloudflare.net`\n    - **Type:** `TXT`, **Name:** `send`, **Content:** `v=spf1 include:_spf.mx.cloudflare.net ~all`\n    - **Type:** `TXT`, **Name:** `cf2024-1._domainkey.send`, Cloudflare\'s DKIM key\n\n    The world sees the MX records too:\n\n    ```bash\n    dig +short MX send.example.com\n    ```\n\n    It lists the three `route` servers. Email Routing\'s **Routing Rules** shows your rule for `newsletter@send.example.com`, and **Destination Addresses** shows the publisher\'s inbox as verified. A reply to your test email in the next step proves the forwarding works.\n\n1. In the editor, **Settings \u2192 Email sender** shows Amazon SES and your From address, where it said **No email provider connected** before.\n\n1. In a browser, `https://newsletter.example.com/subscribe` shows the subscribe form, where it said signups aren\'t open yet.\n\nThe test sends in the next step prove the rest. In the sandbox, send them only to the addresses you verified in section 5, and to the SES test addresses that page lists.\n\nSES charges for each email it sends, test emails included. [Amazon SES pricing](https://aws.amazon.com/ses/pricing/) lists the rates.\n\nNext, [verify it works](05-verify.md).\n';
 
 // docs/get-started/05-verify.md
-var verify_default = "# Verify it works\n\nSome things only show up with real email: whether inboxes trust your mail, how it looks in a real mail client, and whether bounces and unsubscribes come back to the app. Check them now, while your list is empty and every email goes only to you.\n\nIn this guide, you send yourself a test email, reply to it, and check that it passes authentication. Then you set up your notifications, send a real post to yourself as a subscriber, and unsubscribe. Finally, you check that bounces and complaints reach the app, and read the app's logs.\n\n## Before you begin\n\n- Two email addresses you own, such as a personal address and a work address. Some steps use both. While your SES account is in the sandbox, verify both in SES first, as [Connect Amazon SES](04-ses.md#5-request-production-access) describes.\n- A Gmail address, or another mail client that shows a message's original source and an **Unsubscribe** button.\n\n## 1. Send yourself a test email\n\nA test email goes through the same code as a real send. If the test looks right, the real send looks the same.\n\n1. In the editor at `https://newsletter.example.com/dashboard/`, create a post with a subject, a short body, and an image.\n\n1. Select **Send test email**, enter your address, and send it.\n\n1. Open the email. It should arrive in your inbox, not in spam. The image loads and the subject reads as you wrote it. Its **View in browser** link opens \"Nothing here yet\" until the post goes out, and its unsubscribe link opens the page a subscriber sees, marked as a test and showing a sample address. Its button walks through to the confirmation, but a test email unsubscribes no one. Section 5 unsubscribes for real.\n\n1. Reply to it, as a reader would. Reply from an address other than the inbox your From address forwards to, such as your second address. Gmail doesn't show you a message you sent when it comes back to you. Send that address a test email too if you need one. The reply arrives in the inbox you chose in [Connect Amazon SES](04-ses.md#3-receive-replies-at-your-from-address). The app can't see your forwarding, so this is the only proof that readers can reach you. If the reply bounces, check the routing rule and the destination address there.\n\n## 2. Check that it passes authentication\n\nInboxes trust mail that passes DKIM and DMARC for the domain it's from. Passing both is the best single sign that your mail reaches the inbox.\n\n1. Open the test email's original source. In Gmail, open the message's menu and select **Show original**.\n\n1. Find the `Authentication-Results` header. It shows:\n\n    - `dkim=pass` for `send.example.com`\n    - `dmarc=pass` for `send.example.com`\n    - `spf=pass`, for a hostname under `send.example.com`\n\n    With no custom MAIL FROM domain, SPF passes for `amazonses.com` instead. That's expected, and DMARC still passes.\n\nIf a check fails, compare your DNS records with the ones in [Connect Amazon SES](04-ses.md#1-verify-your-sending-hostname). [Sending-domain DNS](../reference/02-sending-domain-dns.md#verify-alignment) explains each result.\n\n## 3. Set up your notifications\n\nKestrel emails you when a send finishes, and right away when one runs into a problem. Notifications go through your email provider. To send them through Cloudflare instead, see [Notifications through Cloudflare's email](../guides/03-notifications.md).\n\n1. In the editor, open **Settings \u2192 Notifications**.\n\n1. Enter your address, and select **Save**.\n\n1. Select **Send a test notification**. It arrives at that address.\n\n## 4. Send a real post to yourself\n\nThis is a real send, to a list of one. It proves the whole path: subscribing, confirming, scheduling, and sending.\n\n1. Open `https://newsletter.example.com/subscribe`, and subscribe with your second address.\n\n1. Open the confirmation email, follow its link, and select **Confirm**. In the editor, **Subscribers** shows the address as **Confirmed**.\n\n1. Open your post, select **Schedule**, and then **Send now**. Every send waits at least five minutes before it goes out, so you can cancel a mistake.\n\n1. Cancel the send, to see that canceling stops it. Then select **Send now** again, and let it go.\n\n1. When the send finishes, the post arrives at your second address. A notification arrives at your first, with the subject `Sent:` and the post's title.\n\n## 5. Unsubscribe\n\nEvery email carries an unsubscribe link, and a header that lets mail clients show their own **Unsubscribe** button. Both work in one step, with no login.\n\n1. Open the post from section 4 in your mail client. It shows an **Unsubscribe** button next to the sender.\n\n1. Select it. In the editor, **Subscribers** shows the address as **Unsubscribed**, and later sends leave it out.\n\n## 6. Check that bounces and complaints come back\n\nWhen an address bounces or marks your mail as spam, SES tells the app through SNS. The app then stops mailing that address. SES has test addresses that act out each case without reaching a real person, and the sandbox lets you mail them.\n\n1. Open `https://newsletter.example.com/subscribe`, and subscribe each test address:\n\n    - `bounce@simulator.amazonses.com`, which bounces\n    - `complaint@simulator.amazonses.com`, which marks your mail as spam\n\n    Each one gets a confirmation email, which bounces or is marked as spam.\n\n1. In the editor, **Subscribers** lists both addresses as **Pending**, each with a **Suppressed** flag. The app never mails a suppressed address again.\n\nIf an address has no flag, SES's events aren't reaching the app. Check the configuration set and the SNS subscription in [Connect Amazon SES](04-ses.md#6-send-bounces-and-complaints-to-sns).\n\n## 7. Read the logs\n\nThe app writes a log line for each thing it does, and Cloudflare keeps them for a few days. Nothing else tells you if the once-a-minute schedule that sends your posts stops, so it's worth knowing where to look.\n\n1. In the Cloudflare dashboard, go to **Workers & Pages**, select `kestrel-production`, and select **Observability**.\n\n1. Filter on `event` equal to `sweep.tick`. A line arrives every minute.\n\n1. Filter on `event` equal to `send.completed`. Your send from section 4 is there.\n\n1. Filter on `level` equal to `error`. A healthy instance shows nothing.\n\nWhen every section gives the result it describes, your instance is ready for subscribers.\n\nNext, [go live](06-go-live.md).\n";
+var verify_default = "# Verify it works\n\nSome things only show up with real email: whether inboxes trust your mail, how it looks in a real mail client, and whether bounces and unsubscribes come back to the app. Check them now, while the list is empty and every email goes only to you.\n\nIn this guide, you send yourself a test email, reply to it, and check that it passes authentication. Then you set up notifications, send a real post to yourself as a subscriber, and unsubscribe. Finally, you check that bounces and complaints reach the app, read the app's logs, check that SES can send to anyone, and clean up the test subscribers.\n\n## Before you begin\n\n- Two email addresses you own, such as a personal address and a work address. Some steps use both. While your SES account is in the sandbox, verify both in SES first, as [Connect Amazon SES](04-ses.md#5-request-production-access) describes.\n- A Gmail address, or another mail client that shows a message's original source and an **Unsubscribe** button.\n\n## 1. Send yourself a test email\n\nA test email goes through the same code as a real send. If the test looks right, the real send looks the same.\n\n1. In the editor at `https://newsletter.example.com/dashboard/`, create a post with a subject, a short body, and an image.\n\n1. Select **Send test email**, enter your address, and send it.\n\n1. Open the email. It should arrive in your inbox, not in spam. The image loads and the subject reads as you wrote it. Its **View in browser** link opens \"Nothing here yet\" until the post goes out, and its unsubscribe link opens the page a subscriber sees, marked as a test and showing a sample address. Its button walks through to the confirmation, but a test email unsubscribes no one. Section 5 unsubscribes for real.\n\n1. Reply to it, as a reader would. Reply from an address other than the inbox your From address forwards to, such as your second address. Gmail doesn't show you a message you sent when it comes back to you. Send that address a test email too if you need one. The reply arrives in the inbox you chose in [Connect Amazon SES](04-ses.md#3-receive-replies-at-your-from-address). The app can't see your forwarding, so this is the only proof that readers can reach the publisher. If the reply bounces, check the routing rule and the destination address there.\n\n## 2. Check that it passes authentication\n\nInboxes trust mail that passes DKIM and DMARC for the domain it's from. Passing both is the best single sign that your mail reaches the inbox.\n\n1. Open the test email's original source. In Gmail, open the message's menu and select **Show original**.\n\n1. Find the `Authentication-Results` header. It shows:\n\n    - `dkim=pass` for `send.example.com`\n    - `dmarc=pass` for `send.example.com`\n    - `spf=pass`, for a hostname under `send.example.com`\n\n    With no custom MAIL FROM domain, SPF passes for `amazonses.com` instead. That's expected, and DMARC still passes.\n\nIf a check fails, compare your DNS records with the ones in [Connect Amazon SES](04-ses.md#1-verify-your-sending-hostname). [Sending-domain DNS](../reference/02-sending-domain-dns.md#verify-alignment) explains each result.\n\n## 3. Set up notifications\n\nKestrel emails the notifications address when a send finishes, and right away when one runs into a problem. Notifications go through your email provider. To send them through Cloudflare instead, see [Notifications through Cloudflare's email](../guides/03-notifications.md).\n\n1. In the editor, open **Settings \u2192 Notifications**.\n\n1. Enter your address, and select **Save**.\n\n1. Select **Send a test notification**. It arrives at that address.\n\nUse your own address to test. If you're not the publisher, they set theirs in [Check your setup](../publishing/10-check-your-setup.md).\n\n## 4. Send a real post to yourself\n\nThis is a real send, to a list of one. It proves the whole path: subscribing, confirming, scheduling, and sending.\n\n1. Open `https://newsletter.example.com/subscribe`, and subscribe with your second address.\n\n1. Open the confirmation email, follow its link, and select **Confirm**. In the editor, **Subscribers** shows the address as **Confirmed**.\n\n1. Open the post, select **Schedule**, and then **Send now**. Every send waits at least five minutes before it goes out, so you can cancel a mistake.\n\n1. Uncheck **Include in archive**. The post still goes to subscribers, but it's sent as email only: it isn't in the public archive or on the home page. That way the test proves the send without becoming the publication's first archived post, and the dashboard keeps its **Finish setting up** steps for the publisher.\n\n1. Cancel the send, to see that canceling stops it. Then select **Schedule** and **Send now** again, check that **Include in archive** is still unchecked, and let it go.\n\n1. When the send finishes, the post arrives at your second address. A notification arrives at your first, with the subject `Sent:` and the post's title.\n\nIf you verified this instance before Email only existed, the test post is in the archive. Open it under **Sent**, and select **Remove from archive\u2026**.\n\n## 5. Unsubscribe\n\nEvery email carries an unsubscribe link, and a header that lets mail clients show their own **Unsubscribe** button. Both work in one step, with no login.\n\n1. Open the post from section 4 in your mail client. It shows an **Unsubscribe** button next to the sender.\n\n1. Select it. In the editor, **Subscribers** shows the address as **Unsubscribed**, and later sends leave it out.\n\n## 6. Check that bounces and complaints come back\n\nWhen an address bounces or marks your mail as spam, SES tells the app through SNS. The app then stops mailing that address. SES has test addresses that act out each case without reaching a real person, and the sandbox lets you mail them.\n\n1. Open `https://newsletter.example.com/subscribe`, and subscribe each test address:\n\n    - `bounce@simulator.amazonses.com`, which bounces\n    - `complaint@simulator.amazonses.com`, which marks your mail as spam\n\n    Each one gets a confirmation email, which bounces or is marked as spam.\n\n1. In the editor, **Subscribers** lists both addresses as **Pending**, each with a **Suppressed** flag. The app never mails a suppressed address again.\n\nIf an address has no flag, SES's events aren't reaching the app. Check the configuration set and the SNS subscription in [Connect Amazon SES](04-ses.md#6-send-bounces-and-complaints-to-sns).\n\n## 7. Read the logs\n\nThe app writes a log line for each thing it does, and Cloudflare keeps them for a few days. Nothing else tells you if the once-a-minute schedule that sends posts stops, so it's worth knowing where to look.\n\n1. In the Cloudflare dashboard, go to **Workers & Pages**, select `kestrel-production`, and select **Observability**.\n\n1. Filter on `event` equal to `sweep.tick`. A line arrives every minute.\n\n1. Filter on `event` equal to `send.completed`. Your send from section 4 is there.\n\n1. Filter on `level` equal to `error`. A healthy instance shows nothing.\n\n## 8. Check that SES can send to anyone\n\n[Connect Amazon SES](04-ses.md#5-request-production-access) asked AWS for production access. Until AWS grants it, the sandbox mails only your verified addresses, so check it before you go live.\n\n1. In SES, open the **Account dashboard** in the region the app sends from. It no longer says your account is in the sandbox, and it shows your daily quota and maximum send rate.\n\n1. Check that `SES_MAX_SEND_RATE` in `wrangler.jsonc` matches that rate, and that you deployed after setting it, as [Connect Amazon SES](04-ses.md#8-set-the-provider-and-deploy) describes.\n\nIf the dashboard still says sandbox, AWS hasn't answered yet. Every other section works in the sandbox, so come back to this one when it does.\n\n## 9. Clean up the test subscribers\n\nThe checks leave test addresses on the list. Erase them, so the publisher starts with only real readers.\n\n1. In the editor, open **Subscribers**.\n\n1. Erase `bounce@simulator.amazonses.com` and `complaint@simulator.amazonses.com`. Open each one's menu (\u22EF), and select **Erase**.\n\n1. Erase your second address too, if it won't be a reader.\n\nErasing keeps a do-not-contact marker, but the person can subscribe again through the subscribe page. Erasing your own address doesn't lock you out.\n\nWhen every section gives the result it describes, your instance is ready for subscribers.\n\nNext, [go live](06-go-live.md).\n";
 
 // docs/get-started/06-go-live.md
-var go_live_default = "# Go live\n\nThis last step makes the newsletter yours, and tells people where to subscribe.\n\nIn this guide, you check your publication's name, add a logo, and share your subscribe link. You also see what to change as your list grows.\n\n## Before you begin\n\n- SES production access, granted in the region the app sends from. [Connect Amazon SES](04-ses.md#5-request-production-access) asks for it.\n- `SES_MAX_SEND_RATE` set to the maximum send rate on the SES **Account dashboard**, and deployed. [Connect Amazon SES](04-ses.md#8-set-the-provider-and-deploy) sets it to `1` for the sandbox.\n\nIn the sandbox, SES refuses the confirmation email to any address you haven't verified, so those signups fail. A post reaches only the addresses you verified in SES.\n\n## 1. Name your publication\n\nYour publication's name, tagline, and logo appear on the public pages readers see, and in every email. You named it in [Connect Amazon SES](04-ses.md#5-request-production-access). Check those, and add a logo before anyone sees your pages.\n\n1. In the editor, open **Settings \u2192 Publication identity**.\n\n1. Check the name and tagline, and upload a logo.\n\n1. **(Optional)** Select **Add a mailing address**. US law asks for a postal address in promotional email, and a P.O. box works. The built-in email template prints it in every email's footer.\n\n## 2. Share your subscribe link\n\nReaders subscribe on a page the app hosts. Every signup confirms by email before it joins your list.\n\n1. In the editor, open **Settings \u2192 Ways to subscribe**.\n\n1. Copy your subscribe page's link, `https://newsletter.example.com/subscribe`, and share it.\n\n1. **(Optional)** To take signups on your own website, copy the embeddable subscribe form from the same page, and paste it into your site.\n\n1. **(Optional)** Cap how often one visitor can submit the form. The app already sends any one address at most one confirmation every 15 minutes. A Cloudflare rule can also limit each visitor, and the Free plan includes one. See [Rate-limit the subscribe form](../guides/05-rate-limit.md).\n\n## As your list grows\n\nA new instance runs on Cloudflare's free Workers plan. As your list grows, three limits come into play.\n\n- **Your SES quota.** AWS caps how many emails your account sends a day. A send that hits the cap waits, and the app emails you. It resumes on its own once the quota frees up, or after AWS raises it.\n- **How fast a send goes out.** A send goes out a slice at a time, one slice a minute. SES takes one request a second, of up to 50 recipients, and no more recipients a second than your account's maximum send rate. So each request carries one second of that rate, up to 50.\n- **Your database's daily writes.** On the free plan, D1, the database the app runs on, allows 100,000 rows written a day. Past that, it refuses every query until midnight UTC, and the whole app stops: sends, signups, the public pages, and the editor.\n\nIt's recommended to move to the $5 Workers Paid plan from about 5,000 subscribers. A send writes about 14 database rows a recipient, delivery receipts included. So one send uses up the free plan's day at about 7,000 recipients, and sooner when an import or anything else writes that day. Workers Paid counts [D1's writes](https://developers.cloudflare.com/d1/platform/pricing/) by the month instead, with 50 million included, and never stops the database for them. On the free plan, the app warns you before a send to more than 5,000 recipients, in the Schedule dialog and on the scheduled post. A smaller send that fires on a day you've imported subscribers gets the same warning on the scheduled post. The app also warns before an import that would use most of a day's writes with the day's earlier imports. It never stops you, since your account may already be on Workers Paid.\n\nThe free Workers plan sends four requests a minute. At 14 messages a second, a common starting rate, that's 56 recipients a minute, and 1,000 subscribers take about 18 minutes. At 50 a second or more, it's 200 a minute.\n\nTo send faster, first ask AWS to raise your maximum send rate to 50, which costs nothing, then set [`SES_MAX_SEND_RATE`](../reference/01-configuration.md#ses_max_send_rate) to match, and deploy again. A rate above 50 adds nothing on the free plan, where a rate of 50 sends 5,000 subscribers in about 25 minutes. A larger list belongs on Workers Paid for its database writes anyway. On Workers Paid, set [`SUBREQUEST_BUDGET`](../reference/01-configuration.md#subrequest_budget) to `10000`. It sends about 50 requests a minute: about 700 recipients at 14 a second, and about 2,500 at 50 or more.\n\n## Check it\n\n1. The SES **Account dashboard**, in the region the app sends from, no longer says your account is in the sandbox.\n\n1. `https://newsletter.example.com/subscribe` shows your publication's name and logo.\n\n1. `https://newsletter.example.com/` shows your publication's name, and the post you sent yourself in [Verify it works](05-verify.md#4-send-a-real-post-to-yourself).\n\n## What's next\n\nEach of these guides stands on its own. Pick the ones you want.\n\n- [Connect Claude to the API](../guides/01-connect-claude.md), so Claude can draft, proofread, and schedule posts through the same API the editor uses.\n- [Notifications through Cloudflare's email](../guides/03-notifications.md), so you hear about problems even when your email provider has stopped sending.\n\nIf someone else writes the newsletter, point them to the docs' Publishing section, written for them, starting with [Bring your existing list](../publishing/01-your-list.md).\n\nWhen a new release comes out, [Upgrade to a new release](../guides/07-upgrade.md) shows how to move to it.\n";
+var go_live_default = "# Go live\n\nAt this point, your instance should be deployed, verified, and out of the SES sandbox, so it can send to anyone. From here, the publisher can set up the publication, and you can continue with the guides below.\n\n## Start publishing\n\nThe rest happens in the editor, at `https://newsletter.example.com/dashboard/`. The Publishing docs walk through it in the order of the dashboard's setup checklist, starting with [Name your publication](../publishing/03-name-your-publication.md).\n\nIf someone else is the publisher, let them sign in first:\n\n1. Add their email address to the `Publishers` policy on the Access application, as in [Allow yourself in](03-access.md#3-allow-yourself-in). If you set `ACCESS_ALLOWED_EMAILS`, store the list again with their address added.\n\n1. If they don't have a Cloudflare account, add another way to sign in, such as a one-time code by email. It's under **Zero Trust \u2192 Integrations \u2192 Identity providers**.\n\n1. Send them the editor's address and a link to [Name your publication](../publishing/03-name-your-publication.md).\n\n## Optional next steps\n\nEach of these guides adds one thing, and you can come back to any of them later.\n\n- [Connect Claude to the API](../guides/01-connect-claude.md), so Claude can draft, proofread, and schedule posts through the same API the editor uses.\n- [Notifications through Cloudflare's email](../guides/03-notifications.md), so problems are reported even when the email provider has stopped sending.\n- [Rate-limit the subscribe form](../guides/05-rate-limit.md), before the subscribe link is shared widely.\n- [As your list grows](../guides/09-as-your-list-grows.md), from about 5,000 subscribers.\n- [Upgrade to a new release](../guides/07-upgrade.md), when one comes out.\n";
 
 // docs/guides/01-connect-claude.md
-var connect_claude_default = '# Connect Claude to the API\n\nClaude Code can draft, edit, proofread, and schedule your posts through the same API the editor uses. It has its own Cloudflare Access credential, so its changes show as Claude\'s, not yours. Anything it schedules waits out the review window, where you can still cancel it.\n\nIn this guide, you create a service token for Claude Code, and add a policy for it to your Access application. Then you store the token where Claude Code reads it, check that it works, and point Claude at the API reference.\n\n## Before you begin\n\nYou need:\n\n- The dashboard locked with Access, from [Lock the dashboard with Access](../get-started/03-access.md).\n- [Claude Code](https://code.claude.com/docs/en/overview), run from your instance\'s repository.\n\n## 1. Create a service token\n\nA service token is a Client ID and a Client Secret that a program sends with each request. It carries no email, so the app tells it apart from your own login.\n\n1. In **Zero Trust**, go to **Access controls \u2192 Service credentials \u2192 Service Tokens**, and select **Create Service Token**.\n\n1. Name it `kestrel-claude`, and choose a **Service Token Duration**. A year is a good default.\n\n1. Select **Generate token**.\n\n1. Copy the **Client ID** and the **Client Secret**. Cloudflare shows the secret only once.\n\n## 2. Add a policy for the token\n\nYour application lets in only the people its `Publishers` policy names. A token needs a policy of its own, on the same application, because the app accepts only logins issued for that application.\n\n1. Under **Access controls \u2192 Applications**, select **Configure** on the application from [Lock the dashboard with Access](../get-started/03-access.md#2-create-the-access-application).\n\n1. Add a policy:\n\n    - **Policy name:** `Claude`\n    - **Action:** Service Auth\n    - **Include:** the **Service Token** selector, with `kestrel-claude`\n\n1. Save the application.\n\n`ACCESS_ALLOWED_EMAILS` doesn\'t apply to the token, since it has no email. This policy is the only thing that lets it in.\n\n## 3. Store the token for Claude Code\n\nClaude Code loads the `env` block of `.claude/settings.local.json` into every session. That file stays on your computer: your repository\'s `.gitignore` keeps it out of git.\n\n1. Open `.claude/settings.local.json` in your instance\'s repository. Create it if it doesn\'t exist.\n\n1. Add an `env` block, beside anything already in the file:\n\n    ```json\n    {\n      "env": {\n        "KESTREL_URL": "https://newsletter.example.com",\n        "CF_ACCESS_CLIENT_ID": "REPLACE_WITH_CLIENT_ID",\n        "CF_ACCESS_CLIENT_SECRET": "REPLACE_WITH_CLIENT_SECRET"\n      }\n    }\n    ```\n\n    `KESTREL_URL` is your app\'s address. The other two are the Client ID and Client Secret from section 1.\n\n1. Start a new Claude Code session, so it loads the values.\n\nNever put the secret in `.claude/settings.json`. That file is committed.\n\n## 4. Point Claude at the API\n\nKestrel has no plugin or connector for Claude. Claude calls the HTTP API directly, and the API reference describes every route: its method and path, the body it takes, and an example. The editor\'s **API** tab shows the same reference.\n\nYour instance\'s `.claude/CLAUDE.md` already tells Claude Code how to call the API, so a session in your instance\'s repository reads the reference before its first call. If it doesn\'t, a prompt like this one points it there:\n\n```\nKestrel\'s API is at $KESTREL_URL. Send the CF-Access-Client-Id and\nCF-Access-Client-Secret headers from your environment with every request.\nRead GET /api/reference first, and use it for every call.\n```\n\nThe reference is also served as Markdown, `GET /api/reference.md`, which reads more easily for Claude than the JSON. So are the docs: `GET /api/docs/publishing.md` lists the publisher\'s pages, `GET /api/docs/self-hosting.md` this guide\'s, and each page is at `GET /api/docs/<slug>.md`.\n\nClaude reads the reference, and from there can list your posts, write a draft, and schedule it. The reference lists the body types each route takes. Most take JSON, sent with `Content-Type: application/json`. An image upload takes a multipart form, or the image file itself.\n\nTo bring your subscribers over from another service, ask Claude to import your list. Your instance\'s `/migrate-list` skill reads the format from `GET /api/imports/format` and converts the old service\'s export to it. It checks Kestrel\'s plan against its own counts, and asks for your attestation before it imports anyone as a subscriber. [Bring your existing list](../publishing/01-your-list.md) explains what an import does, and the [import format](../publishing/08-import-format.md) describes every column.\n\n## Check it\n\n1. Ask Claude to call `GET /api/whoami`. The app answers with a program\'s identity, not yours:\n\n    ```\n    {"principal":{"kind":"service"},"auth":{"mode":"access"}}\n    ```\n\n1. Ask Claude to list your posts. It answers with the posts the editor shows.\n\n1. Open a draft in the editor, and ask Claude to change a word in it. The editor shows that the draft was changed elsewhere, last edited by **Claude**.\n\nIf Claude gets a `401`, a `403`, or a login page, check the policy from section 2, and the token\'s two values in `.claude/settings.local.json`. Check that the token hasn\'t expired, too.\n';
+var connect_claude_default = '# Connect Claude to the API\n\nClaude Code can draft, edit, proofread, and schedule posts through the same API the editor uses. It has its own Cloudflare Access credential, so its changes show as Claude\'s, not a person\'s. Anything it schedules waits out the review window, where the publisher can still cancel it.\n\nIn this guide, you create a service token for Claude Code, and add a policy for it to your Access application. Then you store the token where Claude Code reads it, check that it works, and point Claude at the API reference.\n\n## Before you begin\n\nYou need:\n\n- The dashboard locked with Access, from [Lock the dashboard with Access](../get-started/03-access.md).\n- [Claude Code](https://code.claude.com/docs/en/overview), run from your instance\'s repository.\n\n## 1. Create a service token\n\nA service token is a Client ID and a Client Secret that a program sends with each request. It carries no email, so the app tells it apart from your own login.\n\n1. In **Zero Trust**, go to **Access controls \u2192 Service credentials \u2192 Service Tokens**, and select **Create Service Token**.\n\n1. Name it `kestrel-claude`, and choose a **Service Token Duration**. A year is a good default.\n\n1. Select **Generate token**.\n\n1. Copy the **Client ID** and the **Client Secret**. Cloudflare shows the secret only once.\n\n## 2. Add a policy for the token\n\nYour application lets in only the people its `Publishers` policy names. A token needs a policy of its own, on the same application, because the app accepts only logins issued for that application.\n\n1. Under **Access controls \u2192 Applications**, select **Configure** on the application from [Lock the dashboard with Access](../get-started/03-access.md#2-create-the-access-application).\n\n1. Add a policy:\n\n    - **Policy name:** `Claude`\n    - **Action:** Service Auth\n    - **Include:** the **Service Token** selector, with `kestrel-claude`\n\n1. Save the application.\n\n`ACCESS_ALLOWED_EMAILS` doesn\'t apply to the token, since it has no email. This policy is the only thing that lets it in.\n\n## 3. Store the token for Claude Code\n\nClaude Code loads the `env` block of `.claude/settings.local.json` into every session. That file stays on your computer: your repository\'s `.gitignore` keeps it out of git.\n\n1. Open `.claude/settings.local.json` in your instance\'s repository. Create it if it doesn\'t exist.\n\n1. Add an `env` block, beside anything already in the file:\n\n    ```json\n    {\n      "env": {\n        "KESTREL_URL": "https://newsletter.example.com",\n        "CF_ACCESS_CLIENT_ID": "REPLACE_WITH_CLIENT_ID",\n        "CF_ACCESS_CLIENT_SECRET": "REPLACE_WITH_CLIENT_SECRET"\n      }\n    }\n    ```\n\n    `KESTREL_URL` is your app\'s address. The other two are the Client ID and Client Secret from section 1.\n\n1. Start a new Claude Code session, so it loads the values.\n\nNever put the secret in `.claude/settings.json`. That file is committed.\n\n## 4. Point Claude at the API\n\nKestrel has no plugin or connector for Claude. Claude calls the HTTP API directly, and the API reference describes every route: its method and path, the body it takes, and an example. The editor\'s **API** tab shows the same reference.\n\nYour instance\'s `.claude/CLAUDE.md` already tells Claude Code how to call the API, so a session in your instance\'s repository reads the reference before its first call. If it doesn\'t, a prompt like this one points it there:\n\n```\nKestrel\'s API is at $KESTREL_URL. Send the CF-Access-Client-Id and\nCF-Access-Client-Secret headers from your environment with every request.\nRead GET /api/reference first, and use it for every call.\n```\n\nThe reference is also served as Markdown, `GET /api/reference.md`, which reads more easily for Claude than the JSON. So are the docs: `GET /api/docs/publishing.md` lists the publisher\'s pages, `GET /api/docs/self-hosting.md` this guide\'s, and each page is at `GET /api/docs/<slug>.md`.\n\nClaude reads the reference, and from there can list the posts, write a draft, and schedule it. The reference lists the body types each route takes. Most take JSON, sent with `Content-Type: application/json`. An image upload takes a multipart form, or the image file itself.\n\nTo bring subscribers over from another service, ask Claude to import the list, as [Bring your existing list](../publishing/01-your-list.md) describes. Its [file format](../publishing/01-your-list.md#the-file-format) section describes every column.\n\n## Check it\n\n1. Ask Claude to call `GET /api/whoami`. The app answers with a program\'s identity, not yours:\n\n    ```\n    {"principal":{"kind":"service","tokenId":"e367c0ffee5eb4.access"},"auth":{"mode":"access"}}\n    ```\n\n    The `tokenId` is the Client ID Zero Trust shows beside `kestrel-claude`. If it\'s a different one, Claude Code is using another token.\n\n1. Ask Claude to list the posts. It answers with the posts the editor shows.\n\n1. Open a draft in the editor, and ask Claude to change a word in it. The editor shows that the draft was changed elsewhere, last edited by **Claude**.\n\nIf Claude gets a `401`, a `403`, or a login page, check the policy from section 2, and the token\'s two values in `.claude/settings.local.json`. Check that the token hasn\'t expired, too.\n';
 
 // docs/guides/03-notifications.md
-var notifications_default = "# Notifications through Cloudflare's email\n\nKestrel emails you when a send goes out, and right away when one runs into a problem. By default, these notifications go through your email provider. The one you need most, about your provider refusing your account, is the one your provider would refuse too. Cloudflare's email doesn't depend on your provider, so that notification still reaches you.\n\nIn this guide, you turn on Cloudflare's email for your app's hostname, and verify your own address with it. Then you add the binding that sends notifications through it, deploy, and send yourself a test.\n\n## Before you begin\n\nYou need:\n\n- Your notification address saved, from [Verify it works](../get-started/05-verify.md#3-set-up-your-notifications).\n- Your domain's DNS on Cloudflare, as for the rest of the app.\n\n## 1. Turn on Email Routing for your app's hostname\n\nCloudflare's email sends only from a domain set up with Email Routing. Use your app's hostname, `newsletter.example.com`. It receives no mail today, so turning Email Routing on there changes nothing else.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Compute \u2192 Email Service \u2192 Email Routing**.\n\n1. Add `newsletter.example.com` to Email Routing. Cloudflare adds subdomains from your domain's own settings: select `example.com`, then **Settings**, and add `newsletter` under **Subdomains**.\n\n1. Cloudflare adds MX, SPF, and DKIM records for `newsletter.example.com`, and locks them. Wait until they show as added.\n\nAvoid turning on Email Routing for a domain that already receives mail elsewhere, such as `example.com` with Google Workspace. Email Routing takes over that domain's MX records. Don't send notifications from `send.example.com` either, since your email provider sends from it. Email Routing there to forward readers' replies, as [Connect Amazon SES](../get-started/04-ses.md#3-receive-replies-at-your-from-address) sets up, is fine, since it only receives.\n\n## 2. Verify your address\n\nCloudflare's email delivers only to addresses you've verified with it. Sending to a verified address is free on any plan.\n\n1. Under **Email Routing**, go to **Destination Addresses**, and add the address you saved for notifications.\n\n1. Open the email Cloudflare sends to that address, and select **Verify email address**.\n\nA verified address belongs to your Cloudflare account, so every environment in it can use it.\n\n## 3. Add the binding and deploy\n\nA `send_email` binding named `NOTIFY` moves notifications to Cloudflare's email. Without it, they go through your provider.\n\n1. In `wrangler.jsonc`, add the binding to the `production` block:\n\n    ```jsonc\n    \"send_email\": [\n      { \"name\": \"NOTIFY\", \"allowed_destination_addresses\": [\"you@example.com\"] } // \u2190 your address\n    ],\n    ```\n\n    `allowed_destination_addresses` is optional. It limits the binding to the addresses you list, so a changed setting in the editor can't send notifications anywhere else. Leave it out to allow any address you've verified.\n\n1. **(Optional)** Notifications come from `Kestrel <kestrel@newsletter.example.com>`. To use another address on that hostname, set `NOTIFY_FROM` in the block's `vars`:\n\n    ```jsonc\n    \"NOTIFY_FROM\": \"Kestrel <alerts@newsletter.example.com>\",\n    ```\n\n1. Check the file. This regenerates the binding types:\n\n    ```bash\n    npm run typecheck\n    ```\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am \"Send notifications through Cloudflare's email\"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\n## Check it\n\n1. In the editor, open **Settings \u2192 Notifications**. **Sent through** reads \"Cloudflare Email, separate from your newsletter's provider\", and **From address** shows `kestrel@newsletter.example.com`.\n\n1. Select **Send a test notification**. It arrives at your address, and **Last notification** shows it as delivered.\n\nIf the test isn't delivered, **Last notification** shows Cloudflare's reason, such as an address that isn't verified. Cloudflare's Email Routing summary lists notifications as dropped even when they're delivered, so check your inbox rather than the summary.\n\n## What notifications don't cover\n\n- **The schedule stopping.** The same once-a-minute schedule that sends your posts also notices problems. If the schedule itself stops, nothing tells you. [Read the logs](../get-started/05-verify.md#7-read-the-logs) to check that `sweep.tick` still arrives every minute.\n- **A notification that can't get through.** The app tries each one up to five times, a minute apart. A failure shows under **Settings \u2192 Notifications**, and in the logs as `notify.failed`.\n- **Problems while no address is set.** With the address blank, the app sends nothing, and saves nothing up for later.\n\nA notification never changes a send. One that fails never delays, pauses, or stops it.\n";
+var notifications_default = "# Notifications through Cloudflare's email\n\nKestrel emails the publisher when a send finishes, and right away when one runs into a problem. By default, these notifications go through the email provider. The one that matters most, about the provider refusing your account, is the one the provider would refuse too. Cloudflare's email doesn't depend on the provider, so that notification still reaches the publisher.\n\nIn this guide, you turn on Cloudflare's email for your app's hostname, and verify the notifications address with it. Then you add the binding that sends notifications through it, deploy, and send yourself a test.\n\n## Before you begin\n\nYou need:\n\n- The notifications address saved, from [Verify it works](../get-started/05-verify.md#3-set-up-notifications).\n- Your domain's DNS on Cloudflare, as for the rest of the app.\n\n## 1. Turn on Email Routing for your app's hostname\n\nCloudflare's email sends only from a domain set up with Email Routing. Use your app's hostname, `newsletter.example.com`. It receives no mail today, so turning Email Routing on there changes nothing else.\n\n1. In the [Cloudflare dashboard](https://dash.cloudflare.com/), go to **Compute \u2192 Email Service \u2192 Email Routing**.\n\n1. Add `newsletter.example.com` to Email Routing. Cloudflare adds subdomains from your domain's own settings: select `example.com`, then **Settings**, and add `newsletter` under **Subdomains**.\n\n1. Cloudflare adds MX, SPF, and DKIM records for `newsletter.example.com`, and locks them. Wait until they show as added.\n\nAvoid turning on Email Routing for a domain that already receives mail elsewhere, such as `example.com` with Google Workspace. Email Routing takes over that domain's MX records. Don't send notifications from `send.example.com` either, since your email provider sends from it. Email Routing there to forward readers' replies, as [Connect Amazon SES](../get-started/04-ses.md#3-receive-replies-at-your-from-address) sets up, is fine, since it only receives.\n\n## 2. Verify the notifications address\n\nCloudflare's email delivers only to addresses you've verified with it. Sending to a verified address is free on any plan.\n\n1. Under **Email Routing**, go to **Destination Addresses**, and add the address you saved for notifications.\n\n1. Open the email Cloudflare sends to that address, and select **Verify email address**. If it's the publisher's address, ask them to do this step.\n\nA verified address belongs to your Cloudflare account, so every environment in it can use it.\n\n## 3. Add the binding and deploy\n\nA `send_email` binding named `NOTIFY` moves notifications to Cloudflare's email. Without it, they go through your provider.\n\n1. In `wrangler.jsonc`, add the binding to the `production` block:\n\n    ```jsonc\n    \"send_email\": [\n      { \"name\": \"NOTIFY\", \"allowed_destination_addresses\": [\"you@example.com\"] } // \u2190 the notifications address\n    ],\n    ```\n\n    `allowed_destination_addresses` is optional. It limits the binding to the addresses you list, so a changed setting in the editor can't send notifications anywhere else. Leave it out to allow any address you've verified. If the publisher changes the notifications address later, verify the new one and add it here too.\n\n1. **(Optional)** Notifications come from `Kestrel <kestrel@newsletter.example.com>`. To use another address on that hostname, set `NOTIFY_FROM` in the block's `vars`:\n\n    ```jsonc\n    \"NOTIFY_FROM\": \"Kestrel <alerts@newsletter.example.com>\",\n    ```\n\n1. Check the file. This regenerates the binding types:\n\n    ```bash\n    npm run typecheck\n    ```\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am \"Send notifications through Cloudflare's email\"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\n## Check it\n\n1. In the editor, open **Settings \u2192 Notifications**. **Sent through** reads \"Cloudflare Email, separate from your newsletter's provider\", and **From address** shows `kestrel@newsletter.example.com`.\n\n1. Select **Send a test notification**. It arrives at the notifications address, and **Last notification** shows it as delivered.\n\nIf the test isn't delivered, **Last notification** shows Cloudflare's reason, such as an address that isn't verified. Cloudflare's Email Routing summary lists notifications as dropped even when they're delivered, so check the notifications inbox rather than the summary.\n\n## What notifications don't cover\n\n- **The schedule stopping.** The same once-a-minute schedule that sends posts also notices problems. If the schedule itself stops, nothing tells you. [Read the logs](../get-started/05-verify.md#7-read-the-logs) to check that `sweep.tick` still arrives every minute.\n- **A notification that can't get through.** The app tries each one up to five times, a minute apart. A failure shows under **Settings \u2192 Notifications**, and in the logs as `notify.failed`.\n- **Problems while no address is set.** With the address blank, the app sends nothing, and saves nothing up for later.\n\nA notification never changes a send. One that fails never delays, pauses, or stops it.\n";
 
 // docs/guides/05-rate-limit.md
 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";
@@ -6263,231 +6767,150 @@ var rate_limit_default = "# Rate-limit the subscribe form\n\nThe subscribe form
 // 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. 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\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 kestrel-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. 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\nThe output ends with your app's hostname.\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/05-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/05-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 kestrel-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/08-try-locally.md
-var try_locally_default = "# Try Kestrel locally first\n\nYou can run Kestrel on your own computer to look around before you deploy it. It needs no Cloudflare account and no Git host. Email goes to a stand-in on your computer, so nothing reaches a real inbox.\n\nIn this guide, you write a new instance into an empty folder, start the app, and open the editor. Then you fill it with a demo publication, and empty it again. The folder can become your instance's repository later.\n\n## Before you begin\n\n- [Node.js](https://nodejs.org/) 22 or later\n\n## 1. Write a new instance\n\nAn instance is a small folder of your own. It holds the instance's settings and names the release of Kestrel it runs, which installs from npm as `@kurtbruns/kestrel`.\n\n1. Make an empty folder, and go into it:\n\n    ```bash\n    mkdir newsletter\n    cd newsletter\n    ```\n\n1. Write a new instance into it:\n\n    ```bash\n    npx @kurtbruns/kestrel init\n    ```\n\n    It writes the instance's files, and lists the commands to run next. The folder doesn't need to be a Git repository.\n\n1. Install the release and its tools:\n\n    ```bash\n    npm install\n    ```\n\n## 2. Start the app\n\n1. Copy the local settings:\n\n    ```bash\n    cp .dev.vars.example .dev.vars\n    ```\n\n    They're for your computer only, and send email to the stand-in.\n\n1. Start the app:\n\n    ```bash\n    npm run dev\n    ```\n\n    The first time, it creates the local database and asks you to confirm its migrations. Answer yes. The server keeps running in this terminal, and its output ends with the address it's ready on.\n\n1. Open http://localhost:8787/dashboard/ to see the editor. There's nothing to sign in with on your computer. If another app already uses port 8787, Kestrel picks a free port instead, and the `Ready on` line shows it.\n\n## 3. Load the demo publication\n\nThe demo fills the editor with posts, subscribers, and sends that already went out, so you can see the app in use.\n\n1. In a second terminal, in the same folder, load the demo:\n\n    ```bash\n    npm run seed\n    ```\n\n    It replaces everything in the local database, and lists links to the editor and the demo's published posts.\n\n1. To empty the local database again, and see the app as a new instance starts:\n\n    ```bash\n    npm run reset\n    ```\n\n1. To stop the server, press <kbd>Ctrl</kbd>+<kbd>C</kbd> in its terminal. Your local content stays for the next `npm run dev`.\n\n## Check it\n\n1. The app answers. If `npm run dev` picked another port, use the one on its `Ready on` line here and below:\n\n    ```bash\n    curl http://localhost:8787/health\n    ```\n\n    ```\n    {\"status\":\"ok\",\"service\":\"kestrel\"}\n    ```\n\n1. After `npm run seed`, http://localhost:8787/ shows the demo publication's public landing page, with its posts.\n\n## Keep the folder for your instance\n\nIf you came here from Deploy the app, your folder is already a repository: go back to [Sign in to Cloudflare](../get-started/02-deploy.md#2-sign-in-to-cloudflare).\n\nWhen you're ready to deploy, this folder can be your instance's repository. You need [Git](https://git-scm.com/) and a GitHub account for this part. The folder's `.gitignore` already keeps your local settings, the local database, and the installed packages out of it.\n\n1. On GitHub, [create a new repository](https://github.com/new) named `newsletter`. It can be private. Leave it empty, with no README, license, or `.gitignore`.\n\n1. Make the folder a repository, and commit the instance. Replace `YOUR_USERNAME` with your GitHub username:\n\n    ```bash\n    git init\n    git add -A\n    git commit -m \"Start a Kestrel instance\"\n    git remote add origin https://github.com/YOUR_USERNAME/newsletter.git\n    git push -u origin HEAD\n    ```\n\nThen check [what deploying needs](../get-started/02-deploy.md#before-you-begin) and [choose your hostnames](../get-started/02-deploy.md#choose-your-hostnames). Then [deploy the app](../get-started/02-deploy.md#2-sign-in-to-cloudflare) from signing in to Cloudflare onward.\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. That suits a list of up to about 5,000 subscribers. Past that, two limits matter: how fast SES lets you send, 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 SES **Account dashboard** shows your new rate. In `wrangler.jsonc`, set the `production` block\'s [`SES_MAX_SEND_RATE`](../reference/01-configuration.md#ses_max_send_rate) to match.\n\n1. Commit the change, and push it:\n\n    ```bash\n    git commit -am "Match the SES send rate"\n    git push\n    ```\n\n1. Deploy:\n\n    ```bash\n    npx wrangler deploy --env production\n    ```\n\n## 2. Upgrade to Workers Paid\n\nOn the free plan, [D1](https://developers.cloudflare.com/d1/platform/pricing/) allows a fixed number of database writes a day. A send to about 7,000 recipients uses them all, and then the whole app stops until midnight UTC. Until you upgrade, the app warns the publisher before a send or an import that could use up the day. It\'s recommended to upgrade from about 5,000 subscribers.\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 ([`SUBREQUEST_BUDGET`](../reference/01-configuration.md#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\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. The SES **Account dashboard** shows the maximum send rate you set in `SES_MAX_SEND_RATE`.\n\n1. On Workers Paid, the import screen under **Subscribers \u2192 Import** reads "CSV or .txt, up to 10,000 rows."\n';
 
 // docs/publishing/01-your-list.md
-var your_list_default = "# Bring your existing list\n\nAlmost no one starts a newsletter with an empty list. If your readers are on another service, bring them over before your first post, with the consent they gave there. It's the **Bring your existing list** step on your dashboard, and **Import** starts it. If you're starting fresh, skip this step: new readers join through [Share your subscribe link](09-share-your-subscribe-link.md).\n\nThis page covers the file Kestrel reads, what an import does and why, and the limits. It also covers taking your whole list out again at any time, in the same format. The dashboard's **Subscribers \u2192 Import** walks you through an import, and Claude reads this same page through the API.\n\n## The file Kestrel reads\n\nKestrel reads one documented format, `kestrel-subscribers/1`: a CSV file with a header row and one row per address. A row says what your old service recorded about a person, and Kestrel decides what that means here. Five columns decide what happens to a row:\n\n| Column | What it holds |\n| --- | --- |\n| `email` | The address. Kestrel trims it and ignores capitals when it matches. |\n| `status` | `subscribed`, `pending`, `unsubscribed`, or `none` (an address with no consent claim, present only to carry a bounce or a block). |\n| `opt_in` | How consent was collected: `double`, `single`, or `unknown`. |\n| `origin` | Where consent was collected, as a short name such as `sendy` or `mailchimp`. |\n| `subscribed_at` | When they subscribed, with its time zone, such as `2024-03-01T09:30:00Z`. Optional. |\n\nThe optional columns carry the rest: a bounce or complaint (`suppression`), when someone confirmed or left, and `evidence`, the old service's own consent details, such as a signup IP or a form name. [Import format](08-import-format.md) describes every column and value.\n\nThe import screen's **Download example file (CSV)** gives you `kestrel-import-example.csv`, a few rows that show each case. Open it in a spreadsheet to see the shape, and save your file as CSV UTF-8.\n\nKestrel never guesses what another service's export means, because a wrong guess about who agreed to be emailed can't be taken back. An export in any other shape is refused, with what's wrong and where. Convert it first, with Claude or by hand.\n\n## A plain list of addresses\n\nIf all you have is addresses, a `.txt` file with one address per line works too. After you choose it, you say what the addresses are: **Subscribed** (the default), **Unsubscribed**, or **Bounced**. Every address in the file is that one kind, so a plain list of subscribers and a plain list of bounces are two imports.\n\nA plain list loses what a full CSV carries: how and where each person joined, when, and the evidence. Kestrel records how they joined as unknown. When your old service can export more than addresses, prefer the CSV.\n\n## Let Claude convert your export\n\nExports from Sendy, Mailchimp, Substack, and other services all differ, and change without notice. If you use Claude Code with your instance, ask it to do the conversion:\n\n```\nPlease import my Sendy subscribers from ~/Downloads/sendy-export.csv into the newsletter.\n```\n\nClaude's `/migrate-list` skill reads Kestrel's format from your instance and asks you what anything ambiguous in the export means. It converts a few rows for you to check, then checks Kestrel's plan against its own counts. It asks for your attestation before it imports anyone as a subscriber. [Connect Claude to the API](../guides/01-connect-claude.md) sets Claude up.\n\nIf a scheduled post would reach the people the import adds, Claude stops and asks you to finish in the dashboard: choose the converted file Claude left in your working folder under **Subscribers \u2192 Import**, and the same plan appears for you to confirm.\n\n## What an import does\n\nNothing changes when you choose a file. Kestrel plans the import first and shows you what it would do to every row. You see who is added as a subscriber, who is recorded as having left, and who is suppressed, and which rows are repeats, invalid, or left out. You can download the rows that won't be imported as subscribers, to check them against your file. Only when you press **Import** does anything change, and then the import applies whole, or not at all. If a reader's consent changed between your plan and the import, for example someone unsubscribed or confirmed, their row follows your list as it stands then, and the result lists each row that turned out differently from the plan you saw. An import sends no email.\n\nTo import anyone as a subscriber, you confirm that everyone you're importing as subscribed opted in to receive your publication, and that the list isn't purchased, rented, or scraped. If you're unsure about some people, take them out of the file before importing. Kestrel keeps your attestation with the import's record.\n\nIf a post is scheduled, it goes to the list as it stands when it sends, so the people an import adds would receive it. The plan names each such post and how many more people it would reach, and you acknowledge each one before importing.\n\nIf your list or its scheduled posts changed since the plan in a way the plan rests on, such as another import, Kestrel plans your file again and shows you the new plan as things stand now, before anything happens.\n\n## Why your old service's record is honored\n\nKestrel normally confirms every new subscriber with double opt-in: they click a link in an email before they get any posts. Asking your whole list to confirm again would lose readers who already said yes, and would mail every one of them a request they didn't expect. So an import carries over what your old service recorded instead: the consent each person gave there, how it was collected, and your word for it.\n\nKestrel holds a few lines that an import can't cross:\n\n- **Someone who left stays gone.** An address that unsubscribed here is never subscribed again by an import, whatever the file says. Only that reader can come back, by confirming here.\n- **A bounce, a block, or a do-not-contact marker here always wins.** An import never lifts a suppression, so an address known to fail is never mailed. An address you erased keeps only a do-not-contact marker, and an import never records a subscriber for it again, not even as one who left.\n- **A reader's newer choice stands.** If someone confirmed here after your old service says they left, they stay subscribed.\n- **Repeats are folded together,** and when one row says subscribed and another says unsubscribed, unsubscribed wins.\n\nIn the subscriber list, imported subscribers are **Confirmed** and receive your posts. The **How they joined** column says they were imported, with the service and the opt-in method your file gave, such as \"Imported \xB7 Sendy, single opt-in\". Only someone who confirmed through Kestrel itself reads as \"Double opt-in\". Choose **View subscriber** from a subscriber's \u22EF menu to see the evidence.\n\n## Limits\n\n- **Rows.** One import takes up to 10,000 rows on Workers Paid, or 1,000 on the free plan's limits. The import screen says which applies to you. Split a larger list into several files, and import them one at a time.\n- **Daily database writes on the free plan.** Cloudflare's free plan allows a fixed number of database writes a day, and stops your newsletter until midnight UTC once they're used up. Bringing in a large list, in one file or several, and sending to it on the same day can use them up. So when the day's imports would use most of the day's writes, the plan warns you and suggests importing the file the next day, by UTC, and a post scheduled for a day imports have written warns you too, suggesting it go out the next day. Neither warning stops anything.\n- **When to move to Workers Paid.** From about 5,000 subscribers, it's recommended to move to the $5 Workers Paid plan, which has no daily limit on writes. Whoever runs your Kestrel makes the change, as [Go live](../get-started/06-go-live.md#as-your-list-grows) describes.\n\n## When readers reply\n\nKestrel only sends mail. A reader who replies to a post writes to your From address, so replies reach you once that address forwards to an inbox you read. Whoever runs your Kestrel sets that up outside Kestrel.\n\nWhen a reader replies asking to be taken off the list, carrying it out is up to you, since Kestrel never sees the reply. Find them under **Subscribers**, and choose **Unsubscribe** from their \u22EF menu. It takes effect at once. **Unsubscribe** is there for confirmed readers; one who never confirmed gets no posts, and **Erase** removes them.\n\nWhen a reader asks you to delete their data, choose **Erase** from their \u22EF menu instead. It removes the subscriber and how they joined, and can't be undone. Past send records show an erased recipient in their place. Kestrel keeps only a do-not-contact marker, or the bounce, complaint, or block the address already had, so the address is never mailed again. The reader can still rejoin by subscribing and confirming themselves.\n\n## Taking your list out\n\n**Subscribers \u2192 Export** downloads your whole list as one CSV in the same format: every subscriber with their state, how they joined and the evidence, and every bounced, complained, blocked, or erased address. It's yours to keep as a backup, or to import into another Kestrel, which carries the list over as it is. A value a spreadsheet would run as a formula is written as text, so the file is safe to open.\n\nClaude can read the same export a page at a time through the API, at `GET /api/subscribers/export`.\n\nNext, [Write your first post](04-write-a-post.md).\n";
+var your_list_default = "# Bring your existing list\n\nMoving to Kestrel from another newsletter service means bringing your subscribers with you, along with the consent they gave there. This guide explains how to export your list from the old service, convert it to Kestrel's format, and import it under **Subscribers \u2192 Import**. It also covers what carries over, the limits on an import, and taking your list out again. Kestrel shows you what an import will do before anything changes, and an import never emails your subscribers.\n\n**The first decision is whether to upgrade to Cloudflare's Workers Paid plan.** With more than about 5,000 subscribers, it's recommended to upgrade before you import. The free plan caps database writes per day, and a large import plus a send can use them up. When that happens, the app stops working until midnight UTC. Workers Paid is $5 a month and has no daily cap, and [As your list grows](../guides/09-as-your-list-grows.md) walks through the upgrade.\n\nIf you're starting without a list, skip this step and go on to [Write and send a post](04-write-a-post.md).\n\n## 1. Export from your old service\n\nExport everyone your old service knows about, not only your current subscribers. Unsubscribes and bounces matter too: once imported, Kestrel never mails someone who left or an address that fails. Include any consent details the export offers, such as signup dates, IP addresses, or form names. Kestrel keeps them with each subscriber as evidence of their consent.\n\n## 2. Convert it to Kestrel's format\n\nEvery service's export is different. Kestrel never guesses what one means, because a wrong guess about who agreed to be emailed can't be taken back. So you convert the export first, to one of two kinds of file:\n\n- **A CSV in Kestrel's format (preferred).** One row per address, with its status, how and where consent was collected, and any bounce or complaint. **Download example file (CSV)** on the import screen shows each case. Save your file as CSV UTF-8.\n- **A plain list (`.txt`).** One address per line, all of one kind: subscribed, unsubscribed, or bounced. Nothing else carries over, so use it only when addresses are all you have.\n\nA CSV in Kestrel's format looks like this, with the five columns that decide what happens to each row:\n\n```\nemail,status,opt_in,origin,subscribed_at\nada@example.com,subscribed,double,sendy,2024-03-01T09:30:00Z\ngrace@example.com,subscribed,single,mailchimp,\nedsger@example.com,unsubscribed,unknown,unknown,\n```\n\n[The file format](01-your-list.md#the-file-format), below, describes every column. If you use Claude Code with your instance, it can do the conversion for you, as [Working with Claude](07-working-with-claude.md) describes.\n\n## 3. Import it\n\nUnder **Subscribers \u2192 Import**, choose your file. Nothing changes yet: Kestrel plans the import and shows what it would do to every row. You see who is added, who is recorded as having left, who is suppressed, and which rows are left out. You can download the rows that won't be imported as subscribers, to check them against your file.\n\n**Import** then applies the plan, all of it or none of it. Before it does, you confirm two things when they apply:\n\n- **That everyone you're importing as subscribed opted in** to receive your publication, and the list isn't purchased, rented, or scraped. Kestrel keeps your attestation with the import.\n- **Each scheduled post that would grow.** A post goes to your list as it stands when it sends, so the people you import would receive it.\n\n## What carries over\n\nAsking your whole list to confirm again would lose readers who already said yes. So an import carries over the consent each person gave on your old service, and your word for it. Imported subscribers are **Confirmed** and receive your posts, and **How they joined** shows where they came from, such as \"Imported \xB7 Sendy, single opt-in\".\n\nA few things hold whatever the file says:\n\n- **Someone who unsubscribed here stays unsubscribed,** until they confirm again themselves.\n- **A bounce, a block, or an erasure here always wins.** An import never lifts one.\n- **A reader's newer choice stands.** Someone who confirmed here after your old service says they left stays subscribed.\n\n## Limits\n\n- **Rows.** Up to 10,000 in one import, or 1,000 on Cloudflare's free Workers plan. The import screen says which applies. Split a larger list into several files, and import them one at a time.\n- **Daily writes.** On the free Workers plan, an import or a large send warns you when it would use most of the day's database writes. Neither warning stops anything. [Limits in detail](01-your-list.md#limits-in-detail) gives the numbers.\n\n## Taking your list out\n\n**Subscribers \u2192 Export** downloads your whole list as one CSV in the same format. It holds every subscriber, how they joined, and every bounced, complained, blocked, or erased address. Keep it as a backup, or import it into another Kestrel to carry the list over.\n\n## The file format\n\nThis section defines `kestrel-subscribers/1` in full, for whoever converts a file, by hand or with Claude. The API serves the same definition at `GET /api/imports/format`, generated from the one the importer reads with. It serves the example files at `GET /api/imports/template.csv` and `GET /api/imports/template.txt`. A file's name decides its kind, `.csv` or `.txt`, and anything else is refused.\n\n### The CSV\n\nThe file is a CSV saved as UTF-8 (in a spreadsheet, **CSV UTF-8**). A header row names the columns below, in any order, then each row is one address. A value with a comma, a quote, or a line break in it is wrapped in double quotes. Each quote inside it is written twice, as spreadsheets write it (RFC 4180). Column names are written exactly, in lowercase. A row records what the source claims, never what Kestrel will do: the import decides that, under the rules further down.\n\n| Column | Required | Values | Meaning |\n| --- | --- | --- | --- |\n| `email` | yes | an email address | The address, trimmed and lowercased before it is matched. An invalid one is still a row, counted as invalid and reported, never dropped. |\n| `status` | yes | `subscribed`, `pending`, `unsubscribed`, `none` | The consent claim. `none` is a known address with no consent claim, present only to carry a suppression. |\n| `opt_in` | yes | `double`, `single`, `unknown` | How consent was collected. `unknown` unless the source states it. |\n| `origin` | yes | a short lowercase name | Where consent was first collected, as the file claims it: `sendy`, `mailchimp`, `kestrel`, or `unknown`. |\n| `suppression` | no | `bounce`, `complaint`, `manual`, `erased` | A suppression on top of `status`: the address bounced, complained, was suppressed by hand, or was erased. |\n| `subscribed_at` | no | an instant with its zone | When the person subscribed, if the source states it. |\n| `confirmed_at` | no | an instant with its zone | When the person confirmed, if the source states it. |\n| `unsubscribed_at` | no | an instant with its zone | When the person left, if the source states it. A reader who confirmed in Kestrel after it stays confirmed. |\n| `suppressed_at` | no | an instant with its zone | When the address was suppressed, if the source states it. |\n| `evidence` | no | a JSON object, at most 500 bytes | The source's consent-relevant columns, verbatim, such as a signup IP or a form name. Nothing reads it to decide anything: it is the proof of consent and the audit trail of a conversion. |\n| `format` | no | `kestrel-subscribers/1` | The version the file is written in. A file without it is read as version 1. |\n\nAn instant is a UTC ISO-8601 time with its zone, such as `2024-03-01T09:30:00Z` or `2024-03-01T10:30:00+01:00`. A time without a zone is refused, never interpreted. An optional column may be left out, or left empty on a row.\n\nAny other column is refused, naming it. A source's other columns belong in `evidence`, as JSON. A file whose header names none of these columns isn't in the format at all, and is refused as such.\n\nThe example file, `kestrel-import-example.csv`, shows each case: a double opt-in subscriber with evidence, a single opt-in one, someone who left, and a bounced address. Here are the same four with only the columns they use, since an optional column may be left out:\n\n```\nemail,status,opt_in,origin,suppression,unsubscribed_at,evidence\nada@example.com,subscribed,double,sendy,,,\"{\"\"signup_ip\"\":\"\"203.0.113.7\"\"}\"\ngrace@example.com,subscribed,single,mailchimp,,,\nedsger@example.com,unsubscribed,unknown,unknown,,2025-01-20T08:00:00Z,\nbounced@example.com,none,unknown,unknown,bounce,,\n```\n\n**Versions.** Adding an optional column keeps the version. Changing what a column means makes a new version. Kestrel reads every version it has published, and refuses one it doesn't know, by name.\n\n### The plain list\n\n- One address per line. Each line is trimmed, blank lines are skipped, and CRLF line endings and a UTF-8 byte-order mark are accepted.\n- A line that isn't a single valid address, such as `Name <ada@example.com>` or a typo, counts as invalid. It's listed among the rows left out. One bad line doesn't sink a list.\n- The whole file is refused when it isn't a plain list at all. That's a file that isn't UTF-8 text, or has no valid address in it. It's also one with a comma, tab, or semicolon in a line, since that makes it a table, so a `.csv`.\n- Its rows arrive with `origin: unknown` and `opt_in: unknown`.\n\n### Plan, then commit\n\nAn import happens in two steps. Planning shows what the import would do to every row, against your list as it stands. It changes nothing, so you can plan a file as often as you need. Committing applies the plan, all of it or none of it, and emails no subscriber.\n\nThe commit needs two things from you when they apply:\n\n- **Your attestation,** when anyone would be confirmed: \"Everyone I'm importing as subscribed opted in to receive [your publication]. This isn't a purchased, rented, or scraped list.\" It is kept with the import, with who gave it and when. An import that only unsubscribes or suppresses needs none.\n- **Each send that would grow,** acknowledged by a person. A post goes to the list as it stands when it fires. So an import can add to the audience of a scheduled send, or of one that has just fired and not yet fixed its audience. Claude can attest for you, but can't acknowledge a growing send: you finish that import in the dashboard.\n\nIf another import is committed after you plan, plan again. If your list changes between the plan and the commit in any other way, such as a reader unsubscribing, the commit still goes ahead. Every write checks the list as it stands, and the answer reports any row that turned out differently.\n\n### What an import does to each address\n\nEach row gets exactly one outcome. A row that both changes its status and adds a suppression reports its status outcome, and says it added a suppression too.\n\n| Outcome | When |\n| --- | --- |\n| `create_confirmed` | `subscribed`, with no subscriber and no suppression in Kestrel, and not erased in the file: added as confirmed. |\n| `confirm_pending` | `subscribed`, pending in Kestrel (never confirmed), and not erased in the file: confirmed, and its confirmation link no longer works. |\n| `unchanged` | Already confirmed in Kestrel, or already in the state the row claims. A subscriber who joined through Kestrel keeps their own record. |\n| `mark_unsubscribed` | `unsubscribed`, and confirmed or pending in Kestrel, with no confirmation in Kestrel newer than the row's `unsubscribed_at`: unsubscribed. |\n| `create_unsubscribed` | `unsubscribed`, with no subscriber in Kestrel, and not erased in Kestrel or in the file: recorded as unsubscribed, so the list remembers they left. |\n| `kept_confirmed_newer` | `unsubscribed`, but the reader confirmed in Kestrel after the source's `unsubscribed_at`: their newer action stands. |\n| `kept_unsubscribed` | `subscribed`, but unsubscribed in Kestrel, or pending again after leaving until they confirm in Kestrel themselves. An unsubscribe is never reversed. |\n| `blocked_by_suppression` | `subscribed`, but the address carries a suppression in Kestrel, a do-not-contact marker included: never added or confirmed. Also `unsubscribed`, when the address's suppression in Kestrel is the do-not-contact marker an erasure left. An address erased in the file gets this outcome too, when its row is `subscribed` or `unsubscribed` with no subscriber in Kestrel. So does one that's `subscribed` and pending in Kestrel, which stays pending. The file's `erased` suppression is still added. In each case no subscriber is recorded or confirmed, so an import never brings back an erased person's data. |\n| `suppression_added` | The row carries a suppression and the address has none in Kestrel, or only a do-not-contact marker, and nothing else changes. Applied whatever the row's `status`. |\n| `left_out` | `pending` or `none` with nothing to apply: counted, never confirmed. An import sends no email, so it can't start a confirmation either. |\n| `invalid` | The address isn't valid. |\n| `merged` | A repeat of an address earlier in the file, folded into it. |\n\nA suppression already in Kestrel is never replaced, with one exception. A bounce, a complaint, or a manual suppression replaces a do-not-contact marker left by an erasure, so a known bad address still gets no confirmation. An imported bounce or complaint is kept apart from one Kestrel saw itself, so the list says where each came from.\n\nAnyone can type an address into your subscribe form, which puts a reader who left back to pending until they confirm. An import treats such a reader as unsubscribed, so it never confirms someone who left in Kestrel.\n\n**Repeats of an address** are folded into one row first. Its status is the first of unsubscribed, subscribed, pending, and none that any repeat claims. Its suppression is the first of erased, complaint, bounce, and manual. Its opt-in is the weakest claim. It keeps the earliest consent times and the latest unsubscribe and suppression times, and the origin and evidence of the row whose status won.\n\nA subscriber an import confirmed is **confirmed**, like anyone who confirmed in Kestrel, and gets your posts. How they joined shows beside their state: imported, with the origin and opt-in method the file claimed, and the evidence. That holds even when the file says they confirmed through Kestrel itself. Only a confirmation Kestrel recorded reads as Kestrel's double opt-in, and a subscriber who later confirms in Kestrel becomes Kestrel's own.\n\n### Limits in detail\n\n- **Rows:** up to 10,000 in one import. On the free Workers plan's limits it's 1,000, since that plan's processing time per request can't plan and commit more. [`SUBREQUEST_BUDGET`](../reference/01-configuration.md#subrequest_budget) tells Kestrel which plan it's on.\n- **Size:** an import request of at most 10 MB, and at most 500 bytes of `evidence` a row.\n- **Daily database writes on the free Workers plan:** 100,000 written rows a day. Once they're spent, the app stops working until midnight UTC. Each new subscriber an import brings in writes 7 rows, and a send writes about 14 a recipient. So an import of 1,000 new subscribers uses about 7% of a day, and about ten of them use most of it.\n- **The warnings:** an import's plan warns when it and the day's earlier imports, by UTC, would use more than 70% of the day's writes. It suggests importing the file the next day. A scheduled post warns when its send and that day's imports would use most of the day. With no imports, that's a send to more than 5,000 recipients. It suggests sending the next day, and its banner repeats the warning while it's scheduled. Neither warning stops anything.\n\n### Exporting\n\nThe export reads your whole list out in this format, a page at a time, at `GET /api/subscribers/export`. Each page holds up to 1,000 rows on the free Workers plan's limits, or 10,000 otherwise. Its `next` value asks for the page after it. Following `next` until it's `null` gives every address exactly once, even if the list changes while you read. An address added or removed partway through may or may not appear.\n\nTo make one CSV in this format, write the pages' rows under a single header. The dashboard's **Export** button, on the Subscribers screen, does this for you and downloads the whole list as one CSV. In the CSV, a value that starts with `=`, `+`, `-`, or `@` is written with an apostrophe before it. A spreadsheet then shows it as text rather than running it as a formula, and an import takes the apostrophe off again.\n\nThe export includes every subscriber with how they joined, their evidence, and their suppression. It also includes every address suppressed with no subscriber behind it, written as `status: none`. A confirmed subscriber is written as `subscribed`.\n\nImporting an export into another Kestrel carries the list over: the same states and suppressions, with every confirmation arriving as imported, carrying its original evidence. Pending subscribers are left out on the way in, since an import sends no confirmation.\n";
 
 // docs/publishing/02-sending-rules.md
-var sending_rules_default = "# Sending rules\n\nEmail law asks a few things of every newsletter. Kestrel handles the ones a sending app can, and the rest are yours, since they depend on what you write and whom you write to.\n\nThis page covers what Kestrel handles, what you handle, and how to act on a reader's request to leave or be deleted. It describes US law (CAN-SPAM) unless it says otherwise. It's general information, not legal advice. When your situation is unclear, ask a lawyer.\n\n## What Kestrel handles\n\n- **Consent.** Kestrel mails only people who confirmed they want your newsletter. Someone who subscribes gets an email with a link, and only once they confirm do they receive posts. People you import come with your old service's record of their consent, and your word for it ([Bring your existing list](01-your-list.md#why-your-old-services-record-is-honored)).\n- **Unsubscribing.** Every email has an unsubscribe link, and the one-click unsubscribe header that Gmail and Yahoo ask bulk senders for. It takes effect at once. US law allows up to 10 business days.\n- **Bounces and complaints.** An address that bounces, or a reader who marks your email as spam, is never mailed again. So a bad address can't keep hurting your sending reputation.\n- **Sender authentication.** Your emails are signed with DKIM for your own domain, and SPF and DMARC records in its DNS vouch for them. Whoever runs your Kestrel sets these up, and mailbox providers now expect them.\n\n## What you handle\n\n- **An honest From name and subject line.** The From name should say who the email is from, and the subject should match what's inside. Whoever runs your Kestrel sets the From name and address.\n- **Marking ads as ads.** When an email is an advertisement, say so clearly. In a newsletter that's mostly writing, labeling a sponsor's section is enough.\n- **A mailing address, when an email is commercial.** Most newsletters don't need one. [When to provide a mailing address](03-name-your-publication.md#when-to-provide-a-mailing-address) says when you do, beside where you add one.\n- **Requests readers send you.** A reader who replies to a post writes to your From address. Replies reach you once that address forwards to an inbox you read, which whoever runs your Kestrel sets up. Kestrel never sees a reply, so carrying out what a reader asks is up to you.\n\n## When a reader asks to leave or to be deleted\n\nKestrel offers readers no form for deleting their data, so they ask you. In many places the law gives a reader that right. The European Union's GDPR, for example, may apply if you have readers there.\n\n- **Say how to reach you.** Your privacy notice, wherever you publish it, should say how readers ask you about their data. Replying to any post works once replies reach your inbox.\n- **To stop the email,** find a confirmed reader under **Subscribers**, and choose **Unsubscribe** from their \u22EF menu. It records that they asked, and they can rejoin by subscribing again. A reader who never confirmed gets no posts, so **Erase** is the choice for them.\n- **To stop mailing someone on your own judgment,** not at their request, choose **Block** instead. It stops every email to the address whatever its status, and **Unblock** undoes it.\n- **To delete their data,** choose **Erase** from the same menu. It removes the subscriber and how they joined, and can't be undone. Past send records show an erased recipient in their place. Kestrel keeps the address only so it's never mailed again, as [Bring your existing list](01-your-list.md#when-readers-reply) explains.\n- **Act promptly.** Under the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), you answer within a month in most cases (Article 12). The right to have data deleted is Article 17, and Article 13 asks you to tell readers about it when they sign up.\n\n## Outside the US\n\nOther countries have their own rules, and they often ask more. Canada's anti-spam law (CASL) usually counts more email as commercial, and asks for a mailing address in it ([Government of Canada guidance](https://ised-isde.canada.ca/site/canada-anti-spam-legislation/en)). The GDPR covers how you keep readers' data. If many of your readers live outside the US, check the rules where they live.\n\nThe FTC's [CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) is the plain-language source for the US rules on this page.\n";
+var sending_rules_default = "# Sending rules\n\nEmail law asks a few things of every newsletter. Kestrel handles the ones a sending app can, and the rest are yours, since they depend on what you write and whom you write to.\n\nThis page covers what Kestrel handles, what you handle, and how to act on a reader's request to leave or be deleted. It describes US law (CAN-SPAM) unless it says otherwise. It's general information, not legal advice. When your situation is unclear, ask a lawyer.\n\n## What Kestrel handles\n\n- **Consent.** Kestrel mails only people who confirmed they want your newsletter. Someone who subscribes gets an email with a link, and only once they confirm do they receive posts. People you import come with your old service's record of their consent, and your word for it ([Bring your existing list](01-your-list.md#what-carries-over)).\n- **Unsubscribing.** Every email has an unsubscribe link, and the one-click unsubscribe header that Gmail and Yahoo ask bulk senders for. It takes effect at once. US law allows up to 10 business days.\n- **Bounces and complaints.** An address that bounces, or a reader who marks your email as spam, is never mailed again. So a bad address can't keep hurting your sending reputation.\n- **Sender authentication.** Your emails are signed with DKIM for your own domain, and SPF and DMARC records in its DNS vouch for them. You set them up in [Connect Amazon SES](../get-started/04-ses.md), and mailbox providers now expect them.\n\n## What you handle\n\n- **An honest From name and subject line.** The From name should say who the email is from, and the subject should match what's inside. The From name and address are set when Kestrel is deployed ([Connect Amazon SES](../get-started/04-ses.md#8-set-the-provider-and-deploy)).\n- **Marking ads as ads.** When an email is an advertisement, say so clearly. In a newsletter that's mostly writing, labeling a sponsor's section is enough.\n- **A mailing address, when an email is commercial.** Most newsletters don't need one. [When to provide a mailing address](03-name-your-publication.md#when-to-provide-a-mailing-address) says when you do, beside where you add one.\n- **Requests readers send you.** A reader who replies to a post writes to your From address. Replies reach you once that address forwards to an inbox you read, as [Connect Amazon SES](../get-started/04-ses.md#3-receive-replies-at-your-from-address) sets up. Kestrel never sees a reply, so carrying out what a reader asks is up to you.\n\n## When a reader asks to leave or to be deleted\n\nKestrel offers readers no form for deleting their data, so they ask you. In many places the law gives a reader that right. The European Union's GDPR, for example, may apply if you have readers there.\n\n- **Say how to reach you.** Your privacy notice, wherever you publish it, should say how readers ask you about their data. Replying to any post works once replies reach your inbox.\n- **To stop the email,** find a confirmed reader under **Subscribers**, and choose **Unsubscribe** from their \u22EF menu. It records that they asked, and they can rejoin by subscribing again. A reader who never confirmed gets no posts, so **Erase** is the choice for them.\n- **To stop mailing someone on your own judgment,** not at their request, choose **Block** instead. It stops every email to the address whatever its status, and **Unblock** undoes it.\n- **To delete their data,** choose **Erase** from the same menu. It removes the subscriber and how they joined, and can't be undone. Past send records show an erased recipient in their place. Kestrel keeps only a do-not-contact marker, or the bounce, complaint, or block the address already had, so it's never mailed again. The reader can still rejoin by subscribing and confirming themselves.\n- **Act promptly.** Under the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), you answer within a month in most cases (Article 12). The right to have data deleted is Article 17, and Article 13 asks you to tell readers about it when they sign up.\n\n## Outside the US\n\nOther countries have their own rules, and they often ask more. Canada's anti-spam law (CASL) usually counts more email as commercial, and asks for a mailing address in it ([Government of Canada guidance](https://ised-isde.canada.ca/site/canada-anti-spam-legislation/en)). The GDPR covers how you keep readers' data. If many of your readers live outside the US, check the rules where they live.\n\nThe FTC's [CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) is the plain-language source for the US rules on this page.\n";
 
 // docs/publishing/03-name-your-publication.md
-var name_your_publication_default = "# Name your publication\n\nGive your newsletter a name and a look before your first post. Readers see your name, tagline, and logo in every email and on every public page. It's the first step of **Set up your publication** on your dashboard.\n\nYou set them under **Settings \u2192 Publication identity**. Every email takes its look from one template, which works as it comes and which you can edit on the **Template** page. This page also covers the optional mailing address, what a change does to scheduled posts, and who sets the From name and address.\n\n## Name, tagline, and logo\n\nAll three are optional, and you can change them at any time under **Settings \u2192 Publication identity**. The name and tagline save with **Save changes** in the bar at the bottom of the page. The logo saves the moment you pick it.\n\n- **Name.** Left blank, your publication uses the From name of your emails instead. If that has no name either, your publication goes unnamed, and every page reads whole without one.\n- **Tagline.** A short line under the name.\n- **Logo.** A PNG, JPEG, WebP, or GIF image. Kestrel shows it square everywhere, so a wider or taller image is cropped to its center square. Pick one at least 256 \xD7 256 px. **Replace** swaps it, and **Remove** takes it away.\n\nSent emails never change. An email already sent, and its archive page, keep the logo and name they went out with.\n\n## Where each part appears\n\nYour identity shows in four places:\n\n- **In your emails,** wherever your template prints it. The built-in template signs off each post with your logo, name, and tagline. The sample email under **Settings \u2192 Email template** shows which parts your template prints.\n- **On the public pages readers see.** Your home page, your archive, and each post's page carry your identity. So do the pages for subscribing, confirming, and unsubscribing. Your logo is the browser tab's icon. **Settings \u2192 Reader pages** shows each of these pages as a reader gets it.\n- **In the confirmation email** a new subscriber gets, which opens with your logo, name, and tagline.\n- **In the dashboard.** The top of the sidebar shows your logo, name, and tagline.\n\nA post's page shows your publication as it is now at the top, and the sign-off as it was sent.\n\n## When to provide a mailing address\n\n**Probably not, if your newsletter is mostly your own writing. Yes, if you use it to sell.** The address is optional, and you can add it or remove it at any time.\n\nUS law (CAN-SPAM) requires a postal address in commercial email. That's email whose primary purpose is to advertise or promote a product or service, at any volume. In its [2008 rule](https://www.ftc.gov/sites/default/files/documents/federal_register_notices/definitions-and-implementation-under-can-spam-act-16-cfr-part-316/080521canspamact.pdf), the FTC treats a newsletter someone subscribed to as a \"transactional or relationship\" message instead. That holds when it's mainly content, even with ads mixed in. A subscription that's purely advertising, like a catalog, stays commercial.\n\nAn email whose primary purpose is selling is a different matter. The FTC's [primary-purpose test](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3) looks at what the email says and what its subject line suggests. So you probably need an address in:\n\n- An email that's mainly selling, such as a launch, a sale, a paid course, or event tickets.\n- A post that's mostly sponsor content or promotions.\n- A mixed email whose subject line reads like an ad.\n\nA nonprofit isn't exempt as a kind of sender. What the email says decides it. Canada's anti-spam law (CASL) usually counts more email as commercial, and asks for a mailing address in it too ([Government of Canada guidance](https://ised-isde.canada.ca/site/canada-anti-spam-legislation/en)). Gmail and Yahoo don't ask for one: their [rules for bulk senders](https://support.google.com/a/answer/14229414) are authentication, one-click unsubscribe, and a low spam-complaint rate.\n\n**What counts.** A street address, a USPS P.O. box, or a private mailbox registered with the Postal Service. You never have to publish a home address.\n\n**Adding it.** Under **Settings \u2192 Publication identity**, choose **Add a mailing address**. The built-in template and both starting templates print it in the footer as soon as it's set, and print nothing while it isn't. They keep it off each post's public page, so your address isn't on the web.\n\nIf you've added an address and your template doesn't include `{{ .Publication.Address }}`, Kestrel saves your change and warns you. A line under the address says so in Settings, and the **Template** page says so when you save. If you typed your address into the template yourself, or don't need one, you can ignore the warning.\n\nThis is general information, not legal advice. The FTC's [CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) is the plain-language source, and [Sending rules](02-sending-rules.md) covers the rest of what the law asks of a newsletter.\n\n## The email template\n\nThe template is the layout every post is sent in: HTML with a style block, and variables Kestrel fills in when it sends. There is one template, used by every post. Choose **Template** in the sidebar, or **Edit template \u2192** under **Settings \u2192 Email template**.\n\nYou start from a built-in default. **Start from example** offers two starting templates to replace what's in the editor:\n\n- **Signed:** your post, then your logo, name, and tagline as a sign-off.\n- **Plain:** just your post and the footer links.\n\nBoth put the unsubscribe link, a View in browser link, and your mailing address in the footer, and both end with \"Powered by Kestrel\". From there, edit the HTML as you like, then press **Save changes**. **Discard** throws your edits away.\n\n### Variables\n\nA variable is replaced with its value in each email. Type it exactly as shown, or it renders as empty. The **Variables** list at the bottom of the **Template** page says what each one holds.\n\n| Variable | What it holds |\n| --- | --- |\n| `{{ .Post.Body }}` | Your post, rendered from Markdown. Required. |\n| `{{ .Post.Subject }}` | The post's subject line. |\n| `{{ .Publication.Name }}` | Your publication's name. |\n| `{{ .Publication.Tagline }}` | Your tagline. |\n| `{{ .Publication.Logo }}` | Your logo as an image, or nothing when no logo is set. |\n| `{{ .Publication.LogoURL }}` | Your logo's address, or empty. |\n| `{{ .Publication.Address }}` | Your mailing address, or empty. |\n| `{{ .Email.SentTo }}` | The address this email was sent to. |\n| `{{ .Email.UnsubscribeURL }}` | This reader's one-click unsubscribe link. Required. |\n| `{{ .Email.ViewInBrowserURL }}` | The post's public page. |\n\nKestrel won't save a template without `{{ .Post.Body }}` or `{{ .Email.UnsubscribeURL }}`. Every email has to carry the post and a way to leave. The two **Required** pills above the editor turn green or red as your template gains or loses them.\n\n### Email-only parts\n\nWrap part of the template in `{{ if .IsEmail }}` and `{{ end }}` to keep it off each post's public page. The starting templates wrap the unsubscribe link, the View in browser link, and the mailing address this way. To show your address on the web too, move it outside the wrapped part.\n\n### Test the template\n\nThe sample email at the top of the **Template** page shows the layout with sample content. Mail apps each draw email their own way, so send yourself a test to see it in a real inbox.\n\n**Send test email** sends a sample post through your saved template, to the addresses you choose. Your default test recipients, from **Settings \u2192 Default test recipients**, fill in first. With unsaved edits, the button reads **Save & send test**, since a test always uses the saved template.\n\n## Changes and scheduled posts\n\nWhen you schedule a post, Kestrel makes its email then, with your template and identity as they stand. So when you change the template, or a part of your identity the template prints, Kestrel makes each scheduled post's email again. Nothing changes until you confirm.\n\nWhen you save, a dialog lists the scheduled posts by subject and send time. Each email's look changes, while its content and send time stay the same. **Save and apply** goes ahead, and **Cancel** leaves your edits unsaved. A logo upload or removal asks the same way.\n\nAfterwards, each of those posts says its look changed since your last test. The mark shows in the editor and on the dashboard until you send a fresh test. Send one, since your earlier test no longer shows what goes out. [Scheduling and sending](05-scheduling-and-sending.md) covers tests of a scheduled post.\n\n- **Changing a part the template doesn't print** asks nothing, since it doesn't change any email.\n- **A post about to send** blocks the change. Kestrel says when you can try again, once that post has gone out.\n- **Posts already sending or sent** never change.\n\n## Who sets the From name and address\n\nWhoever runs your Kestrel sets the From name and address your emails come from. You can't change them in the dashboard, and **Settings \u2192 Email sender** shows them read-only. [Connect Amazon SES](../get-started/04-ses.md#8-set-the-provider-and-deploy) covers setting them.\n\nNext, [Check your setup](10-check-your-setup.md).\n";
+var name_your_publication_default = "# Name your publication\n\nGive your newsletter a name and a look before your first post. Set the name, tagline, and logo under **Settings \u2192 Publication identity**. They appear in every email your template prints them in, on the public pages readers see, and in the confirmation email new subscribers get.\n\nAll three are optional, and you can change them at any time. How they appear in each email comes from your email template, which you can [edit](11-email-template.md).\n\n## When to provide a mailing address\n\n**If your newsletter is mostly your own writing, you probably don't need one. If an email is mainly selling something, add one.**\n\nUS law (CAN-SPAM) asks for a postal address in commercial email. The FTC [treats a newsletter people subscribed to](https://www.ftc.gov/sites/default/files/documents/federal_register_notices/definitions-and-implementation-under-can-spam-act-16-cfr-part-316/080521canspamact.pdf) as a relationship message instead, even with a few ads in it. An email whose main purpose is to sell, such as a launch, a sale, or a sponsor's promotion, is commercial. Canada's law (CASL) asks for an address more often ([Government of Canada guidance](https://ised-isde.canada.ca/site/canada-anti-spam-legislation/en)).\n\nA P.O. box or a registered private mailbox counts, so you never have to publish your home address. To add one, choose **Add a mailing address** under **Settings \u2192 Publication identity**. The built-in templates print it in the email footer and keep it off your public pages.\n\nThis is general information, not legal advice. The FTC's [CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) has the detail, and [Sending rules](02-sending-rules.md) covers the rest of what the law asks of a newsletter.\n\n## Who sets the From name and address\n\nThe From name and address your emails come from are set when Kestrel is deployed, so **Settings \u2192 Email sender** shows them read-only. To change them, follow [Connect Amazon SES](../get-started/04-ses.md#8-set-the-provider-and-deploy).\n\n";
 
 // docs/publishing/04-write-a-post.md
-var write_a_post_default = "# Write your first post\n\nYou write a post in Markdown, in the editor. Kestrel saves it as you type and shows you the exact email under **Preview**. A test sends that same email to any inbox you name.\n\nThis page covers the subject and slug, the Markdown Kestrel reads, images, and saving. It also covers sharing a post with Claude or another tab, the preview, and test emails. It stops where scheduling starts.\n\n## Start a post\n\n**New post**, on the Dashboard or on **Drafts**, creates a draft and opens it in the editor. A draft stays under **Drafts** until you schedule it, and you can edit it as often as you like until then.\n\nTo remove a draft, choose **Delete draft** from its \u22EF menu under **Drafts**. Its saved versions and images go with it, and it can't be undone.\n\n## The subject and the slug\n\nThe **Subject** is the email's subject line. It also names the post in your lists and sets its web address. A post needs a subject before you can schedule it.\n\nThe **Slug** is the last part of the post's public address. Every post you send gets a permanent page in your publication's archive, and every email links to it. With the default setup, a post with the slug `spring-update` lives at `newsletter.example.com/archive/spring-update`. Whoever runs your Kestrel chose the part before the slug, as [Configuration](../reference/01-configuration.md#archive_base_path) describes.\n\nWhile **Auto-generate from subject** is checked, the slug follows the subject, so \"Spring update\" becomes `spring-update`. Type a slug of your own to set it by hand, and it stops following the subject. Clear the field, or check the box again, to have it follow the subject.\n\nA slug uses lowercase letters, numbers, and hyphens, and Kestrel converts what you type to that form. No two posts share a slug, drafts included. When the one a post would take is already held, Kestrel adds a number, such as `spring-update-2`. The field shows the slug the post really has, so it can update a moment after you change the subject.\n\nA draft's slug can change until you schedule it, and a test email sent before a change links to the old address. Once the post is scheduled, its address never moves. **Web version \u2197** shows the post's public page as it will look, and the address it will have.\n\n## Markdown\n\nKestrel reads Markdown in GitHub's flavor and turns it into the body of your email template. The toolbar covers the common cases: **Heading**, **Bold**, **Italic**, **Quote**, **Code**, **Link**, **Bulleted list**, **Numbered list**, and **Indent**. \u2318B, \u2318I, and \u2318K work too.\n\nTables and strikethrough work as well, since they're part of GitHub's Markdown. How a mail client draws them varies, and so does code, so check anything unusual in a test email.\n\nA few things work differently in an email:\n\n- **Line breaks.** A single line break inside a paragraph doesn't start a new line. Leave a blank line between paragraphs.\n- **HTML.** You can write HTML where Markdown falls short. Kestrel removes scripts, `<style>` blocks, forms, and event handlers, since no email needs them. Style a piece with an inline `style` attribute instead.\n- **The inbox preview.** The snippet a mail client shows beside the subject comes from the start of your post. There's no separate field for it, so make the opening lines count.\n- **The plain-text version.** Every email also carries a plain-text version made from the same post. A link becomes its text followed by its address, and an image becomes its alt text.\n\n## Images\n\nTo add an image, paste it, drop it on the composer, or click **Paste, drop, or click to add images** below it. Kestrel uploads the file to the post and inserts a reference by its file name, such as `![cover.jpg](cover.jpg)`. The reference is only the name, never an address to paste.\n\nThe words in square brackets are the image's alt text, which screen readers read aloud and many mail clients show while images are blocked. Kestrel starts it as the file name, so replace that with a short description: `![A stack of paperbacks on a windowsill](cover.jpg)`.\n\n- **Formats.** PNG, JPEG, WebP, or GIF. SVG isn't accepted, since most email apps don't show it.\n- **Size.** Up to 5 MB per image. Kestrel doesn't shrink the file, and every reader downloads it, so a smaller file opens faster. An image wider than the email's column is shown at the column's width.\n- **Warnings.** The preview and each test warn you about an image with no alt text, or a reference to a file the post doesn't have.\n\nImages are public, so any mail client and your archive page can load them. You can add or replace images only while the post is a draft. Uploading a file with the same name as an earlier one replaces it. Once a post is scheduled its images are fixed, and a sent post's images stay, so its emails and archive page keep showing them. Deleting a draft deletes its images.\n\n## Saving and versions\n\nThe editor saves on its own, after a short pause in your typing and never more than half a minute late. **Save draft**, or \u2318S, saves at once.\n\nBeside **Save draft**, the save cue says where you stand: Unsaved, Saving\u2026, or Saved. If a save fails, the cue turns red with \"Not saved:\" and the reason, until a save succeeds. After a dropped connection the editor tries again on its own.\n\nEvery save keeps a whole version of the post. The editor doesn't show that history, but Claude can read it, as [Working with Claude](07-working-with-claude.md) describes.\n\n## When someone else edits the same post\n\nKestrel never lets one save silently overwrite another. That matters when the same post is open in a second tab or browser, or Claude is editing it for you.\n\nWhen another writer saves a newer version, a banner says so and names who, with Claude's saves shown as \"Claude\". It appears while you're still writing, not only when you save. Saving pauses until you choose:\n\n- **Reload** loads their version, and discards your unsaved edits.\n- **Keep editing** keeps yours, and your next save replaces their version.\n\nBoth choices lose something, so read what changed before you pick. If the post is scheduled elsewhere, the banner says it can no longer be edited here. If it's deleted elsewhere, the editor says so and returns to **Drafts**.\n\n## Preview\n\n**Preview** shows the post as the email, made by the same code that makes your test emails and the send itself. It saves your latest edits first, so what you see is the post as it stands. Any warnings, such as a missing subject or alt text, show beneath it.\n\nThree views show the post, each for one purpose:\n\n- **Preview** is the email, for a quick look at layout.\n- **Send test email** is the email in a real inbox, where rendering finally counts.\n- **Web version \u2197** is the post's public archive page, before it's public.\n\nInside the preview, the email's \"view in browser\" link opens the web version, since the public page doesn't exist until the post sends. Mail clients each draw email a little differently, so trust a test over the preview.\n\n## Test emails\n\n**Send test email** opens a dialog that takes one or more addresses, one per line. Each gets its own copy of the email, and nobody on your list receives anything. The addresses in **Settings \u2192 Default test recipients** fill the dialog for you.\n\nA test is the real email. It saves your draft first, then sends it through the same template and code as the send to your list. So a clean test means a clean send. Once a post is scheduled, a test sends the exact copy that will go out.\n\nWhen some addresses don't get the test, the dialog stays open with only those left, and says why. **Send test** again tries just those, so no one gets a second copy.\n\nA few links in a test behave differently from the real send:\n\n- **Unsubscribe.** A test carries an unsubscribe link and the one-click unsubscribe header, so you can check both. Neither unsubscribes anyone. The link opens the page a subscriber sees, marked as a test and showing a sample address.\n- **View in browser.** The link points at the post's public address, which shows a page saying the post appears there once it's sent. It works once the send starts.\n\nA test needs an email provider. Until whoever runs your Kestrel connects one, the editor lets you write and preview but not send tests. [Connect Amazon SES](../get-started/04-ses.md) is their step.\n\n## Next\n\nWhen the test looks right, [Scheduling and sending](05-scheduling-and-sending.md) covers putting the post on the schedule. On a new publication, finish setting up first: [Share your subscribe link](09-share-your-subscribe-link.md).\n";
-
-// docs/publishing/05-scheduling-and-sending.md
-var scheduling_and_sending_default = `# Scheduling and sending
-
-Every post goes out on a schedule. Scheduling makes the email and locks the post, and the send stays visible and cancelable until its time comes. That window is your review, and nothing can skip it, not even **Send now**.
-
-This page covers scheduling, what it freezes, canceling, moving the send time, and sending now. It also covers who receives a post, and what happens when it goes out.
-
-## Scheduling a post
-
-**Schedule** at the foot of the editor opens a dialog where you pick a time under **Send at**, then confirm with **Schedule**. The post goes out at that time, and until then you can cancel it or move it.
-
-The time you pick must be at least the minimum lead away. That's five minutes, unless whoever runs your Kestrel set it differently ([Configuration](../reference/01-configuration.md#min_lead_seconds)). A time closer than that is refused under the picker, with the reason. The lead isn't a setting in the dashboard, and Claude can't change it either. So every send gets a window to catch a mistake, including one Claude prepared.
-
-Send times are to the minute. A time with seconds is rounded up to the next whole minute, which only lengthens the window.
-
-A post needs a subject to schedule. If the subject is empty, pressing **Schedule** marks the **Subject** field with "Add a subject before you schedule." An empty body gets a warning, not a refusal.
-
-After you schedule, you stay on the post. A toast names the send time and suggests you send yourself a test, since the window is where you review. The post now shows the scheduled banner: "Scheduled for" the time, with a countdown ("Sends in \u2026"), and **Reschedule** and **Cancel** beside it.
-
-You manage a scheduled post from that banner, or from the **Scheduled** card on **Sent**. The dashboard's **Scheduled** card shows the countdown and opens the post.
-
-## What scheduling freezes
-
-Scheduling makes the email once, from the post, your email template, and your publication's details as they are at that moment. That frozen copy is what goes out, and it's also the post's page in your archive.
-
-So the post is locked while it's scheduled. It opens on **Preview**, which shows the frozen copy. On **Edit**, you can still read, select, and copy the text, and the composer's foot says "Cancel the schedule to edit". **Send test email** still works, and sends you the frozen copy that will go out.
-
-To change the post's content, cancel the schedule, edit, test again, and schedule it again. That resets your review, so your last test is always of the copy that sends.
-
-A change to your template, or to a publication detail the template shows, is different. It re-makes the email of every scheduled post, at the same send times, with the same content. Kestrel asks before it saves, in a dialog confirmed with **Save and apply**. Afterwards each re-made post's banner asks you to send a new test. The dashboard's card reads "Look changed since your last test" until you do. A save like this is refused while any scheduled post is within the minimum lead of its send time. The refusal says when to try again. [Name your publication](03-name-your-publication.md) covers the template and those details.
-
-## Canceling
-
-**Cancel** on the scheduled banner, or on the **Scheduled** card on **Sent**, stops the send at once. No confirmation is asked, since nothing is lost: the post is a draft again, editable, and you can schedule it again whenever you like.
-
-You can cancel until the send time itself. From then the banner reads "Preparing to send\u2026" and its buttons are unavailable, because the email is going out. A cancel that arrives just after the send time is refused with "Too late to cancel: the send time has passed, so this email is going out."
-
-## Moving the send time
-
-**Reschedule** moves when a scheduled post sends, without canceling it. It opens the same time picker, and **Reschedule** confirms it. The content stays frozen, your tests still count, and the post stays cancelable until the new time.
-
-The new time follows the same rule as scheduling: at least the minimum lead away. Like canceling, you can move a send only before its send time.
-
-## Sending now
-
-Under the time picker in the Schedule dialog, "Or send as soon as possible." leads to **Send now \u2192**. It's for a post you've already reviewed and want out without picking a time.
-
-Sending now still goes through the review window. The **Send now?** view says how many recipients it reaches and when, such as "in 5 to 6 minutes". The range is the minimum lead, plus rounding up to the next minute. Confirm with **Send now**, and the post is locked and scheduled for that time, cancelable until then like any other.
-
-## Who receives it
+var write_a_post_default = "# Write and send a post\n\nYou write a post in Markdown, test it, and schedule it. Scheduling locks the post and makes the exact email that will go out. Then you send yourself a test of that copy, so the email you tested is the one your list receives.\n\n**New post**, on the Dashboard or under **Drafts**, opens a draft.\n\n## Writing\n\nKestrel's editor is a Markdown editor. You write a post in Markdown, the way you would for a static site generator or with an AI assistant. Kestrel places it in your [email template](11-email-template.md). The same Markdown makes the email and the post's archive page, so you never format a post twice. **Preview** shows the email as it will look, and Kestrel saves as you type.\n\nA few things to know as you write:\n\n- **A blank line starts a new paragraph.** In an email, a single line break doesn't.\n- **The opening lines** are the preview a mail client shows beside the subject.\n- **Images** go in by paste or drop, and Kestrel inserts a reference by file name, such as `![cover.jpg](cover.jpg)`. Replace the words in brackets with a short description. PNG, JPEG, WebP, or GIF, up to 5 MB each.\n- **Where it will go** is in **Post settings**, at the top right: whether it's in your archive, and its address, such as `newsletter.example.com/archive/spring-update`, whose slug follows the subject (below).\n\n## Test it\n\n**Send test email** sends the real email, through the same template and code as the send, to the addresses you name. **Settings \u2192 Default test recipients** fills them in for you. Nobody on your list gets anything, nothing appears in your archive, and a test's unsubscribe link unsubscribes no one.\n\nMail clients each draw email a little differently, so trust a test over **Preview**, especially for tables, code, and HTML. A test needs an email provider, which [Connect Amazon SES](../get-started/04-ses.md) sets up.\n\n## Schedule and send\n\nChoose **Schedule** at the foot of the editor, pick a time under **Send at**, and confirm. The time must be at least the minimum lead away: five minutes, unless your deployment sets a different [`MIN_LEAD_SECONDS`](../reference/01-configuration.md#min_lead_seconds). Neither the dashboard nor Claude can shorten it. Times are to the minute, and one with seconds rounds up.\n\nScheduling makes the email once, from the post, your template, and your publication's details as they are at that moment. That frozen copy is what goes out, and it's also the post's page in your archive. So the post is locked, and **Preview** and **Send test email** show the frozen copy.\n\n**Send yourself a test now.** It's the copy your list receives, and the time until the send is your window to catch a mistake, including one Claude made.\n\nChanging your template, or a publication detail it shows, re-makes the email of every scheduled post, with the same content and send time. Kestrel asks before it saves, and each re-made post then asks you to send a new test. A change is refused while a post is within the minimum lead of its send time, and Kestrel says when to try again. Posts already sending or sent never change.\n\n**Send now \u2192**, under the time picker, is for a post you've already reviewed. It still waits out the window, scheduling the post for the minimum lead from now.\n\n### Post settings\n\n**Post settings**, at the top right of the editor, holds two choices. Neither is part of the email, so both stay open while the post is scheduled. Nothing changes until you select **Save**.\n\n**Include in archive** is checked unless you uncheck it. Unchecked, the post goes to your list as usual but is sent as email only: it stays off your public archive and your home page, and its archive address shows nothing. Use that for a post meant for the inbox: a correction to an earlier email, a short-lived notice, or a test. The editor marks such a post **Email only**.\n\n**Archive address** is where the post's page will be in your archive. Only the last part, the slug, is yours to type; it follows the subject until you do. Each post's address is its own: if you type one another post has, or one with spaces or capitals, Kestrel says so and keeps the address as it was. If another post already has the address your subject would give, Kestrel adds a number (`spring-update-2`) and tells you, so you can choose another. The address is fixed once the post starts sending.\n\nThe Schedule, Send now, and Edit schedule dialogs show the same settings under the time, so you can still change them there. A change made in a dialog applies when you schedule, send, or save, and canceling leaves the post as it was. Once a post is scheduled, its banner names where it's going.\n\nEvery email links its web version through the post's own **unlisted link**, which never changes. It opens the archive page while the post is in your archive, and the page itself while it's email only. Anyone with the email can open it, but nothing lists it, and search engines are asked not to.\n\nA sent post's page under **Sent** shows its address with **Remove from archive\u2026** or **Add to archive\u2026**. Both ask first. Removing a post takes its archive address down, so links people shared stop working, but the address stays the post's: add it back and those links work again. Neither changes what was sent.\n\n### Changing your mind\n\n**Cancel**, on the post's banner or its card under **Sent**, makes the post a draft again at once. Edit it, test again, and schedule it again. **Edit schedule** changes the send time, whether the post is in your archive, or both, without unlocking the post, and your tests still count. You can do either until the send time.\n\n### Who receives it\n\nA post goes to your list as it stands when it sends: every confirmed subscriber, except addresses that bounced, complained, or were blocked. Someone who confirms while it's scheduled receives it. Someone who unsubscribes before their email is handed to your provider doesn't, even partway through the send.\n\nSo a recipient count shown before the send is a snapshot. An import that adds subscribers while a post is scheduled adds them to its audience too, and asks you first ([Bring your existing list](01-your-list.md#3-import-it)).\n\n### Warnings when you schedule\n\n- **No email provider connected.** The Schedule dialog can't schedule until one is connected ([Connect Amazon SES](../get-started/04-ses.md)). If the provider goes after a post is scheduled, the post is held, stays cancelable, and goes out once one is connected.\n- **Daily database writes.** On Cloudflare's free Workers plan, a large send may use up the day's writes. The dialog warns you without stopping you, as [Bring your existing list](01-your-list.md#limits) explains.\n\n### When it sends\n\nAt the send time, the post moves to its send page under **Sent**, where you can watch it go out. From then it can't be edited, canceled, or moved. Its page goes up at the same moment, showing exactly the copy that was sent, so every email's \"view in browser\" link works. Whatever interrupts a send, such as your provider's daily quota running out, it waits and resumes where it stopped. No reader gets the same post twice.\n\nIf a send needs your attention, the send page and the dashboard say so. [Troubleshooting](06-troubleshooting.md) covers each case.\n";
 
-A post goes to your list as it stands when it sends: every confirmed subscriber, except addresses that bounced, complained, or were blocked. Someone who confirms while the post is scheduled receives it. Someone who unsubscribes before their email is handed to your email provider doesn't, even partway through the send.
+// docs/publishing/06-troubleshooting.md
+var troubleshooting_default = `# Troubleshooting
 
-So the recipient count the **Send now?** view shows is a snapshot, not a promise. An import that adds subscribers while a post is scheduled adds them to its audience too. The import asks you to acknowledge that first ([Bring your existing list](01-your-list.md#what-an-import-does)).
+When a send needs you, its page and the dashboard's health block say so in a red or amber line. Red needs you to act, and amber is worth a look. Find the line's words below for what it means and what to do.
 
-## Warnings in the Schedule dialog
+**Set a notifications address, so a problem reaches you without your watching.** Set it under **Settings \u2192 Notifications**, in **Send notifications to**. With none set, Kestrel emails you nothing. [Notifications](06-troubleshooting.md#notifications), below, lists what you're told.
 
-The Schedule dialog warns you about two things before you schedule.
+## A send is waiting or held
 
-- **No email provider connected.** The dialog says the post can't be scheduled yet, and its buttons are unavailable. Connecting a provider is for whoever runs your Kestrel, as [Connect Amazon SES](../get-started/04-ses.md) describes. If the provider goes after a post is scheduled, its banner reads "Will be held: no email provider is connected." The post stays cancelable, and goes out once a provider is connected.
-- **Daily database writes.** On the Workers Free plan's limits, a large send may use up the day's database writes, which stops your newsletter until midnight UTC. The dialog warns you, and the post's banner repeats the warning for as long as it's scheduled. It never stops you from scheduling. [Bring your existing list](01-your-list.md#limits) explains the limit and when it's worth moving to Workers Paid.
+A problem with your email provider never marks anyone unsent. The send waits where it is, and carries on from there once the problem clears. "No one has been marked unsent because of this" means this problem: readers whose own email failed earlier stay unsent.
 
-## When it sends
+- **"The provider is refusing the account".** Your provider won't take mail from your account, and its own words follow, with the fix and who makes it. The fix is almost always in your Amazon SES account or Kestrel's deployment, made by whoever runs it. [What SES refuses, and the fix](#what-ses-refuses-and-the-fix), below, lists each one. Any other post that comes due meanwhile waits with it, without asking SES, and you're told once. While a quota frees up a few at a time, or while the SES sandbox takes only your verified addresses, SES takes some readers on each retry and refuses the rest: those it takes are sent, and the line stays, with the time it began, until SES takes everyone it's asked to.
+- **"The provider is refusing this send".** SES refuses this post's email itself, or a batch of it as invalid, rather than your account. Its words follow. Other posts go out as usual. If SES's words name a reader's address, remove that subscriber: the send skips them and carries on at its next retry. If SES refuses the email itself, the email can't change once its send has started, so whoever runs the deployment asks AWS Support why, quoting SES's words.
+- **"No email provider is connected".** The send is held until one is connected ([Connect Amazon SES](../get-started/04-ses.md)), and goes out once it is.
+- **"The provider is unavailable".** An outage or a rate limit on the provider's side. The send reads **Backing off** and says when it next retries, spacing its retries out up to an hour apart while the outage lasts, so there's nothing to do. Any other post that comes due meanwhile waits with it.
+- **"The provider keeps refusing for its sending rate".** An amber line. SES has refused the first request of several retries in a row for its sending rate, which a short burst never does, so Kestrel is set to send faster than your SES account allows. Whoever runs the deployment sets \`SES_MAX_SEND_RATE\` to the **Maximum send rate** on the SES console's **Account dashboard** (1 a second in the sandbox), and deploys, as [Connect Amazon SES](../get-started/04-ses.md#8-set-the-provider-and-deploy) describes. The send retries on its own meanwhile.
+- **"Nothing has gone out for \u2026".** A send has handed off no one for half an hour, with no retry or provider problem to explain it. The part of Kestrel that sends has stopped or keeps failing on this send, or another send going out at the same time is taking all of its turn. A large send going out slowly never shows this. If another send is going out, this one picks up once it finishes. Read the app's logs, as [Read the logs](../get-started/05-verify.md#7-read-the-logs) describes, and check the Worker's trigger, as [\`triggers.crons\`](../reference/01-configuration.md#triggerscrons) describes. The send carries on from where it stopped once it runs again, mailing no one twice.
+- **"The fire time passed \u2026 and the send has not started".** The Cloudflare Cron Trigger that starts sends on time isn't running. The send goes out as soon as it runs again. Check the Worker's trigger, as [\`triggers.crons\`](../reference/01-configuration.md#triggerscrons) describes.
+- **"The provider never answered for \u2026".** Rarely, Kestrel can't tell whether your provider took some emails, and sending again could mail those readers twice. **Resolve\u2026** on the send's page asks you to decide. **Assume not sent** is the safe default: those readers may miss this post, but get your next one. Choose **Assume sent** only when you know they got it.
 
-At the send time, the post moves from the editor to its send page under **Sent**, where you can watch it go out. If you have the post open, the page switches over with a toast saying why. From here the post can't be edited, canceled, or moved.
+## Before a send
 
-A send goes out a slice at a time. A large list takes several slices, and between them the send still reads **Sending**, with "Paused between ticks. It resumes on the next sweep."
+- **A test says "The provider refused it".** Your provider didn't take the test, and its own words follow, with the fix where Kestrel knows it. Sending again gets the same answer until that's fixed. While Amazon SES is in its sandbox, it sends only to addresses verified in SES, so verify the address you test with in the SES console, or request production access, as [Connect Amazon SES](../get-started/04-ses.md#5-request-production-access) describes. Words about the account, such as a key or the sending domain, point at the same fix as [a send the provider refuses](06-troubleshooting.md#a-send-is-waiting-or-held).
+- **A test says "The provider didn't answer, so the test may have arrived".** Kestrel can't tell whether your provider took it. Check the inbox before you send again, since a second test may arrive twice.
+- **"The template or publication details changed this email's look after your last test".** Send a new test of the post, since your last one no longer shows what goes out.
+- **The daily database writes warning.** On Cloudflare's free Workers plan, a large send may use up the day's writes, and then the app stops working until midnight UTC. [Bring your existing list](01-your-list.md#limits) explains the limit, and when to upgrade to Workers Paid.
 
-If your email provider refuses to take more, for example because your account's daily sending quota is spent, the send waits. Nobody is marked unsent, and it tries again on its own, picking up where it stopped once the quota frees up. Raising the quota is for whoever runs your Kestrel ([As your list grows](../get-started/06-go-live.md#as-your-list-grows)).
+## Reading a send's record
 
-Whatever interrupts a send, it resumes rather than starting over. No reader is ever mailed the same post twice.
-
-[After a send](06-after-a-send.md) covers what the send page shows once it's out: the record, bounces, complaints, unsent recipients, and your archive page.
-`;
-
-// docs/publishing/06-after-a-send.md
-var after_a_send_default = `# After a send
-
-Once a send starts, Kestrel keeps a permanent record of it: who it went to, and what happened to each email. The post goes up on its public page in your archive at the same moment, exactly as it was sent. Nothing about either can be edited, and you don't have to watch: Kestrel emails you when the send finishes, and when something needs you.
-
-This page covers a send's record, unsent recipients, bounces and complaints, your notifications, the dashboard's views, and the post's public page.
-
-## The send's record
-
-Every send has its own page, which you open from **Sent** or from the dashboard's **Sent** list. While the send goes out, the page is a live view of its progress. Once it finishes, the same page becomes its record, in place.
-
-The record opens with five counts, over everyone the send went to:
+A send's page becomes its permanent record once it finishes. Its counts cover everyone the send went to:
 
 | Count | What it means |
 | --- | --- |
-| **Recipients** | Everyone the send went to: your confirmed subscribers who weren't suppressed when it started. |
-| **Delivered** | Emails your provider confirmed reached the reader's mail server. |
-| **Bounced** | Emails the receiving server turned away. |
-| **Complained** | Readers who marked the email as spam. |
-| **Unsent** | Recipients Kestrel couldn't hand to your email provider. [Unsent recipients](#unsent-recipients), below, says why. |
+| **Delivered** | Your provider confirmed the email reached the reader's mail server. |
+| **Bounced** | The receiving server turned the email away. |
+| **Complained** | The reader marked the email as spam. |
+| **Unsent** | Kestrel couldn't hand the email to your provider. |
 
-A line under the counts accounts for every recipient by name, so the numbers always add up. It also names two kinds the counts leave out. A recipient **accepted, awaiting a delivery receipt** was taken by your email provider, with no word yet on what happened next. A **skipped** recipient unsubscribed or was suppressed before their turn, so they were never mailed.
+Delivered always means confirmed, not just accepted by your provider. Confirmations can lag by days, so counts keep rising after a send finishes. Some emails are never confirmed at all, so a send can read **Settling** for good, which is normal, as long as some receipts have come.
 
-Below that is the full list of recipients. It opens on **Failures** (bounced, complained, and unsent), and **Delivered** and **All** are one click away. You can search it by address. Each row shows the outcome, the provider's own words about it, and when it happened. A person you erased reads as **Erased recipient** in place of their address. **Export recipients (CSV)** downloads the whole list.
+**"No delivery receipt has arrived for any of \u2026".** An hour after a send went out, Kestrel has heard back about none of its readers. Your provider's reports probably aren't reaching Kestrel, so its bounces and complaints suppress no one, and your next post mails those addresses again. Look for \`webhook.refused\` errors in the app's logs, as [Read the logs](../get-started/05-verify.md#7-read-the-logs) describes. It names the SNS topic that reached Kestrel and the one it expects. Then check the subscription in [Connect Amazon SES](../get-started/04-ses.md#9-subscribe-the-app-to-the-topic). The line goes as soon as a receipt arrives.
 
-### Accepted, then settled
+**Unsent recipients** are still on your list, and get your next post. A recipient is unsent when their own email kept failing, or their address isn't one SES accepts, with the provider's words on the row, or when you chose **Assume not sent**.
 
-Delivery happens in two stages, and the record keeps them apart. First Kestrel hands each email to your email provider, which accepts it, usually within minutes. Later, the provider reports what happened to each email: delivered, bounced, or complained. Those reports can lag by seconds or by days.
+### What SES refuses, and the fix
 
-So a send is **sent** once every recipient has been handed off. Its record then keeps updating as reports arrive. The page says **Settling** while it waits, and **Complete** once every accepted email is confirmed. Some accepted emails are never confirmed at all, so a send can stay **Settling** for good. That's normal, not a fault.
+When SES refuses your account or a send, the red line carries SES's words and the fix. Almost every fix is made by whoever runs the deployment, in the SES console or the deployment's settings.
 
-"Delivered" in Kestrel always means confirmed, never just accepted. So a count can rise for days after a send finishes, and an email can be accepted without ever showing as delivered.
+| SES says | What it means | The fix |
+| --- | --- | --- |
+| Email address is not verified, naming a reader | The SES account is still in the sandbox, which mails only verified addresses. | Request production access on the SES console's **Account dashboard**, as [Connect Amazon SES](../get-started/04-ses.md#5-request-production-access) describes. Signups fail until then, and you're emailed about it once a day. |
+| Email address is not verified, naming your From address or its domain | The sending identity isn't verified in this SES region. | Verify the From address or its domain in SES, in the region the deployment sends from. |
+| Mail FROM domain is not verified | SES can't read the custom MAIL FROM domain's MX record. | Check that record in DNS, or set the identity's **Behavior on MX failure** to use the default MAIL FROM domain. |
+| Daily message quota exceeded | The 24-hour sending quota is spent. It frees up on its own. | In the sandbox (200 a day), request production access. Otherwise, ask AWS for a higher quota, as [As your list grows](../guides/09-as-your-list-grows.md) describes. |
+| Sending paused (account) | AWS paused the account under review, or sending was turned off by hand. | Follow AWS's email to the AWS account's address, or turn sending back on. |
+| Sending paused (configuration set) | Sending is turned off on the configuration set, by hand or by an alarm. | Turn sending back on for that set. |
+| Account suspended | AWS shut down the account's sending. | Only AWS can lift it: open a case with AWS Support. |
+| An access key, signature, or permission error | The deployment's SES key is wrong, expired, or lacks permission. | Replace the key, or give it \`ses:SendEmail\` and \`ses:SendBulkEmail\`. |
+| A subscription is needed (OptInRequired) | The AWS account isn't signed up for SES. | Enable SES for the account, or settle its activation or billing with AWS. |
+| Configuration set does not exist | \`SES_CONFIGURATION_SET\` names a set that isn't in this region. | Fix the name, or create the set. |
+| Sending pool not found | The configuration set uses a dedicated IP pool that doesn't exist. | Pick an existing pool in the set's sending options, or remove it. |
+| The message was rejected | SES refuses this email itself. | Ask AWS Support why. Other posts go out as usual. |
+| The request is invalid | SES refused a batch of this send. | If SES's words name a reader's address, remove that subscriber. |
 
-## Unsent recipients
-
-An unsent recipient never got this post, and is still on your list. They get your next post as usual.
-
-A recipient is recorded unsent in two cases:
-
-- **Their own email kept failing.** When handing off one address hits a passing error, Kestrel tries again a few times, then records it unsent. The row's detail gives the provider's words.
-- **You chose Assume not sent.** Rarely, Kestrel can't tell whether your provider took some emails. The send waits for you, and **Resolve\u2026** on its page asks you to decide. **Assume not sent** is the safe default: those readers may miss this post, but no one is mailed twice.
-
-A problem with your email provider itself never marks anyone unsent. While the provider is down, or refusing your account, the send waits and tries again. Once the problem is fixed, it carries on from where it stopped.
+A server error from SES may come after SES already took the emails, so Kestrel never sends that batch again: its readers wait for **Resolve\u2026**, as for "The provider never answered for \u2026".
 
 ## Bounces and complaints
 
-A bounce or a complaint usually arrives after the send has finished, and lands on the record when it does. Kestrel acts on it for you, so a bad address can't keep hurting your sending reputation:
+Kestrel acts on these for you, so a bad address can't keep hurting your sending reputation:
 
-- **A hard bounce** means the address can't receive mail, such as one that doesn't exist. Kestrel suppresses it, so it's never mailed again.
-- **A soft bounce** is temporary, such as a full mailbox. It's counted on the record, and the address stays on your list.
-- **A complaint** means the reader marked your email as spam. Kestrel suppresses the address, so it's never mailed again.
+- **A hard bounce** means the address can't receive mail. Kestrel never mails it again.
+- **A soft bounce** is temporary, such as a full mailbox. The address stays on your list.
+- **A complaint** means the reader marked your email as spam. Kestrel never mails them again.
 
-The record's list says **Hard bounce** or **Soft bounce** on each row. A suppression doesn't change anyone's subscription. Under **Subscribers**, a suppressed address keeps its status and carries a label saying why: **bounced**, **complaint**, **blocked**, or **erased**. **Legend**, beside the counts, says what each label means. Choose the **suppressed** count to list only those subscribers. [Sending rules](02-sending-rules.md#what-kestrel-handles) says why this matters to mailbox providers.
-
-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 it's worth finding out why.
+Under **Subscribers**, a suppressed address keeps its status and carries a label saying why. 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.
 
 ### Lifting a suppression
 
-Kestrel never lifts a suppression on its own, and neither does an import. Only you can, deliberately. Do it only when you know the address works again, such as a reader who tells you their mailbox is fixed. Mailing an address that keeps bouncing, or a reader who marked you as spam, can hurt every send after it.
-
-A block is yours to lift: **Unblock** in the subscriber's \u22EF menu, which asks you to confirm. It's offered for a block you made, or one an import brought. The dashboard has no control for lifting a bounce or a complaint, but Claude can do it for you through the API, as [Working with Claude](07-working-with-claude.md) describes. Lifting a suppression changes nothing on past records: the bounce or complaint stays where it happened.
-
-## Notifications
+Lift 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. **Unblock**, in a subscriber's \u22EF menu, lifts a block. The dashboard can't lift a bounce or a complaint, but [Claude](07-working-with-claude.md) can, when you ask. Past records keep the bounce or complaint where it happened.
 
-Kestrel emails you when a send finishes, and when a send runs into a problem it can't settle on its own. So you only need to open the dashboard to act.
+## An import is refused
 
-Set the address under **Settings \u2192 Notifications**, in **Send notifications to**. **Send a test notification** checks that one arrives. With no address set, Kestrel sends nothing, and doesn't save anything up for later.
+Kestrel refuses a file it can't read with certainty, and says what's wrong and where. Nothing on your list changes.
 
-You're told:
+- **Not in the format.** The file isn't a Kestrel CSV or a plain list. Convert it first, with Claude or by hand.
+- **A column or value the format doesn't take,** named with its row and column. Fix it in the file, or move a column of your old service's into \`evidence\`.
+- **Too many rows** for one import. Split the file.
+- **Too large.** An import takes up to 10 MB.
 
-- **When a send finishes,** with how many emails your provider accepted, how many were unsent, and how many were skipped.
-- **When your provider refuses your account,** with the provider's own words and what they point to. Amazon SES reports a spent daily quota this way too.
-- **When a send is held because no email provider is connected,** and that it goes out once one is.
-- **When a send stays in progress too long.**
-- **When a send waits for you to resolve it.**
-- **When a send missed its time,** going out late or not at all.
-- **When Claude imports a list for you,** with what the import changed.
+[The file format](01-your-list.md#the-file-format) describes what each column takes.
 
-Each notification links straight to the page it's about. Each event is told once, not again while it lasts, and the dashboard keeps showing it until it clears. A bounce spike is shown on the dashboard, but isn't emailed.
-
-The **Last notification** row in the same section says whether the latest one was **Delivered** or **Not delivered**. Notifications are separate from your newsletter: one that fails never delays or changes a send.
-
-Whoever runs your Kestrel chooses how notifications are sent. By default they go through your newsletter's own email provider. Then the one about your provider refusing your account can't reach you, since that provider would refuse it too. Whoever runs your Kestrel can send them another way that avoids this, as [Notifications through Cloudflare's email](../guides/03-notifications.md) describes.
-
-## Seeing what's happening
-
-The **Dashboard** shows what needs you first, then what's going on:
-
-- **A health block,** only when something needs your attention, such as a send waiting for you to resolve it. Red needs you to act; amber is worth a look.
-- **Active sends,** a card for each send going out now, with its progress.
-- **Subscribers,** counts of **Confirmed**, **Pending**, **Unsubscribed**, and **Suppressed**. Each opens the list filtered to that group.
-- **Sent,** your five latest sends, each with its **Delivered** count and a link to its public page.
-
-**Sent** in the sidebar has the rest: anything that needs attention, your scheduled sends, sends in progress, and every send so far. Search them by subject, or turn on **With delivery failures** to list only sends with a bounce, a complaint, or an unsent recipient.
-
-Wherever a send is listed, its number is **Delivered**, with any complaints, bounces, or unsent recipients named beside it. Every page keeps up on its own, so you never need to reload.
-
-While a send goes out, its page shows two bars. The first fills as your provider accepts each email, and the second fills behind it as deliveries are confirmed. A label beside the subject says how it's going, such as **Sending**, **Retrying**, or **Backing off**.
-
-## The post's public page
-
-Your post goes up in your archive the moment its send starts. So the "view in browser" link in every email works as soon as it lands. Its publish date is the day its send started.
+## Notifications
 
-The page shows the exact copy that was sent, never a fresh rendering of it. Kestrel adds a light frame for the browser: your publication's name, the publish date, a link back to the archive, and a way to subscribe. It also leaves out the parts that only make sense in an inbox, such as the unsubscribe link and your mailing address. No reader's address ever appears on it.
+With an address set, Kestrel emails you:
 
-A sent post can't be changed, and neither can its page. The sign-off shows your publication as it was when you sent the post, while the frame shows it as it is now. The page's address is permanent, so links to it keep working.
+- when a send finishes, with how many emails were accepted, unsent, and skipped
+- when your provider refuses your account or a send, or no provider is connected
+- when the SES sandbox refuses a signup's confirmation, at most once a day
+- when a send stops going out with nothing to explain it, waits for you to resolve it, or misses its time
+- when Claude imports a list for you
 
-Open it from **View published post \u2197** on the send's record, or **Archive \u2197** in the dashboard's **Sent** list. **View publication \u2197** in the sidebar opens your home page, which links into your archive. [Name your publication](03-name-your-publication.md) says where your name, logo, and address appear.
+Each links to the page it's about, and is sent once while the problem lasts. A bounce spike shows on the dashboard but isn't emailed. **Send a test notification** checks that one arrives.
 
-Next, see what Claude can do for you through the same API in [Working with Claude](07-working-with-claude.md).
+By 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.
 `;
 
 // docs/publishing/07-working-with-claude.md
-var working_with_claude_default = "# Working with Claude\n\nClaude works through the same API as the dashboard, so it can do what you do in the dashboard, and nothing more. It drafts, proofreads, tests, schedules, and reports, and everything it changes shows in the dashboard as Claude's.\n\nThis page covers what to ask Claude for, the lines the app holds for any client, and the lines Claude keeps on its own. Setting Claude up is a job for whoever runs your Kestrel: [Connect Claude to the API](../guides/01-connect-claude.md) walks through it. Claude reads these same pages from your Kestrel, so it explains things in the words you see here.\n\n## What to ask Claude\n\nAsk in plain words, the way you'd ask a colleague. Claude reads the API reference, `GET /api/reference`, before its first call, and works out the rest.\n\n- **Draft a post.** Give it your notes, an outline, or a topic, and it saves a draft you can open in the dashboard. Images are uploaded to the post and referenced by file name, as [Write your first post](04-write-a-post.md) describes.\n- **Edit or proofread a post.** Claude saves a new version against the one it read. If you edited the post meanwhile, its save is refused, and it reads your version and works from that, or asks you.\n- **Send a test.** Claude sends the real email to your test addresses, or to one you name, through the same render as the send.\n- **Schedule a post.** Name the post and when it should go out. Claude schedules it, sends a test of exactly what will fire, and tells you when it fires and how to cancel. It can also cancel a send or move its fire time, as [Scheduling and sending](05-scheduling-and-sending.md) describes.\n- **Check a send's record.** Ask how a post did, and Claude reads the send and its recipients. It reports how many were accepted, delivered, and unsent, and any bounces or complaints. [After a send](06-after-a-send.md) says what each one means.\n- **Lift a bounce or a complaint.** The dashboard lifts only a block, with **Unblock**, so ask Claude when you know a bounced address works again. [After a send](06-after-a-send.md#lifting-a-suppression) says when that's wise.\n- **Import a list.** Ask Claude to bring your subscribers over from another service. Its `/migrate-list` skill converts the export, checks it with you, and imports it. [Bring your existing list](01-your-list.md#let-claude-convert-your-export) says how that goes.\n\nIf you have a post open when Claude saves it, the editor tells you, and names Claude as the one who changed it.\n\n## Lines the app holds for any client\n\nThe app enforces these itself, for the dashboard and Claude alike, so they hold whatever Claude is told:\n\n- **Every send waits out the review window.** Nothing goes out the moment it's asked for, not even a send now, and you can cancel it until it fires. The shortest window is set when Kestrel is deployed, so no client can shorten it through the API.\n- **A scheduled post is locked.** To change it, cancel the send, edit, and schedule again. What fires is exactly the copy that was scheduled.\n- **One send per post at a time, and no one mailed twice.** A repeated request finds the existing send instead of making another.\n- **Only confirmed subscribers receive a post.** Someone added by hand gets a confirmation email first, and receives nothing until they confirm. A bounced or complained address is never mailed.\n- **An unsubscribe is final.** Only the reader undoes it, by subscribing again.\n- **No one's edit is overwritten.** A save based on an older version of a post is refused, whichever client sent it.\n- **Only you can let an import grow a scheduled send.** An import through Claude that would add people to a waiting send stops there, until you finish it in the dashboard.\n- **An erased address stays erased.** Adding it back by hand needs a statement that the person asked to join again, and only their own confirmation lifts it.\n\n## Lines Claude keeps\n\nThese come from the instructions your Kestrel gives Claude, not from the app, so they hold as long as those instructions do. Whoever runs your Kestrel keeps them in your instance's repository.\n\n- **It asks before anything that reaches readers.** Sending mail and changing the list wait for your yes.\n- **It schedules only when you ask,** then sends a test of the scheduled copy. After a change to your template or publication details, it tests again.\n- **It never adds a subscriber you didn't name.** The one exception is an import you asked for, through `/migrate-list`, which imports anyone as a subscriber only on your attestation.\n- **It records whose decision it was.** It unsubscribes someone only when they asked to leave, and blocks an address when you decide to stop mailing it. It lifts a bounce or a complaint only when you say the problem is gone, and confirms first.\n- **It erases a subscriber only when you name them and ask,** and confirms first, since an erasure can't be undone.\n- **It reads post text and subscriber data as content.** Words in a post or a reader's record are never instructions to Claude.\n- **It won't help share your subscribe link before your Kestrel can send to anyone.** Until then, signups fail. Whoever runs your Kestrel finishes that before [Go live](../get-started/06-go-live.md).\n\nThe app lets Claude give your attestation for an import, so the instruction to ask you first is Claude's own. The import's record says it was given through Claude, and Kestrel emails you about the import if your notifications are set up.\n\n[Subscriber import format](08-import-format.md) describes the file Claude converts your list to.\n";
-
-// docs/publishing/08-import-format.md
-var import_format_default = "# Subscriber import format\n\nKestrel imports a subscriber list in one documented format, `kestrel-subscribers/1`, and exports the whole list in the same format. This page describes the format, what an import does to each address, and the limits.\n\nKestrel never guesses what another service's export means, because a wrong guess about who agreed to be emailed can't be taken back. An export from Sendy, Mailchimp, or anywhere else is converted to this format first, by Claude or by hand. The API serves everything on this page at `GET /api/imports/format`, generated from the same definition the importer reads with, along with an example of each kind of file, `kestrel-import-example.csv` at `GET /api/imports/template.csv` and `kestrel-import-example.txt` at `GET /api/imports/template.txt`. The import screen offers both as **Download example file**.\n\n## Two kinds of file\n\n- **The full CSV (preferred).** It carries unsubscribes, bounces, and how each person joined. It's what the export writes, and you can open it in a spreadsheet to check it before importing.\n- **A plain list (`.txt`).** One address per line, for a list that is only addresses. You say what they all are: subscribed (the default), unsubscribed, or bounced. Nothing else carries over: not how or when each person joined, when anyone left, or any evidence of their consent. And since every address is the one kind you choose, unsubscribes and bounces each need a file of their own.\n\nThe file's name decides which it is: `.csv` or `.txt`. Anything else is refused.\n\n## The CSV\n\nA CSV file saved as UTF-8 (in a spreadsheet, **CSV UTF-8**), with a header row of the column names below, in any order, then one row per address. A value with a comma, a quote, or a line break in it is wrapped in double quotes, with each quote inside written twice, as spreadsheets write it (RFC 4180). Column names are written exactly, in lowercase. A row records what the source claims, never what Kestrel will do: the import decides that, under the rules further down.\n\n| Column | Required | Values | Meaning |\n| --- | --- | --- | --- |\n| `email` | yes | an email address | The address, trimmed and lowercased before it is matched. An invalid one is still a row, counted as invalid and reported, never dropped. |\n| `status` | yes | `subscribed`, `pending`, `unsubscribed`, `none` | The consent claim. `none` is a known address with no consent claim, present only to carry a suppression. |\n| `opt_in` | yes | `double`, `single`, `unknown` | How consent was collected. `unknown` unless the source states it. |\n| `origin` | yes | a short lowercase name | Where consent was first collected, as the file claims it: `sendy`, `mailchimp`, `kestrel`, or `unknown`. |\n| `suppression` | no | `bounce`, `complaint`, `manual`, `erased` | A suppression on top of `status`: the address bounced, complained, was suppressed by hand, or was erased. |\n| `subscribed_at` | no | an instant with its zone | When the person subscribed, if the source states it. |\n| `confirmed_at` | no | an instant with its zone | When the person confirmed, if the source states it. |\n| `unsubscribed_at` | no | an instant with its zone | When the person left, if the source states it. A reader who confirmed in Kestrel after it stays confirmed. |\n| `suppressed_at` | no | an instant with its zone | When the address was suppressed, if the source states it. |\n| `evidence` | no | a JSON object, at most 500 bytes | The source's consent-relevant columns, verbatim, such as a signup IP or a form name. Nothing reads it to decide anything: it is the proof of consent and the audit trail of a conversion. |\n| `format` | no | `kestrel-subscribers/1` | The version the file is written in. A file without it is read as version 1. |\n\nAn instant is a UTC ISO-8601 time with its zone, such as `2024-03-01T09:30:00Z` or `2024-03-01T10:30:00+01:00`. A time without a zone is refused, never interpreted. An optional column may be left out, or left empty on a row.\n\nAny other column is refused, naming it. A source's other columns belong in `evidence`, as JSON. A file whose header names none of these columns isn't in the format at all, and is refused as such.\n\nThe example file, `kestrel-import-example.csv`, shows each case: a double opt-in subscriber with evidence, a single opt-in one, someone who left, and a bounced address. Here are the same four with only the columns they use, since an optional column may be left out:\n\n```\nemail,status,opt_in,origin,suppression,unsubscribed_at,evidence\nada@example.com,subscribed,double,sendy,,,\"{\"\"signup_ip\"\":\"\"203.0.113.7\"\"}\"\ngrace@example.com,subscribed,single,mailchimp,,,\nedsger@example.com,unsubscribed,unknown,unknown,,2025-01-20T08:00:00Z,\nbounced@example.com,none,unknown,unknown,bounce,,\n```\n\n**Versions.** Adding an optional column keeps the version. Changing what a column means makes a new version. Kestrel reads every version it has published, and refuses one it doesn't know, by name.\n\n## The plain list\n\n- One address per line. Each line is trimmed, blank lines are skipped, and CRLF line endings and a UTF-8 byte-order mark are accepted.\n- A line that isn't a single valid address, such as `Name <ada@example.com>` or a typo, is counted as invalid and listed among the rows left out. One bad line doesn't sink a list.\n- The whole file is refused when it isn't a plain list at all: not UTF-8 text, a line with a comma, tab, or semicolon (it's a table, so a `.csv`), or not one valid address in it.\n- Its rows arrive with `origin: unknown` and `opt_in: unknown`.\n\n## Plan, then commit\n\nAn import happens in two steps. Planning shows what the import would do to every row, against your list as it stands, and changes nothing, so you can plan a file as often as you need. Committing applies the plan, all of it or none of it, and sends no email.\n\nThe commit needs two things from you when they apply:\n\n- **Your attestation,** when anyone would be confirmed: \"Everyone I'm importing as subscribed opted in to receive [your publication]. This isn't a purchased, rented, or scraped list.\" It is kept with the import, with who gave it and when. An import that only unsubscribes or suppresses needs none.\n- **Each send that would grow,** acknowledged by a person. A post goes to the list as it stands when it fires, so an import can add to the audience of a scheduled send, or of one that has just fired and not yet fixed its audience. Claude can attest for you, but can't acknowledge a growing send: you finish that import in the dashboard.\n\nIf another import is committed after you plan, plan again. If your list changes between the plan and the commit in any other way, such as a reader unsubscribing, the commit still goes ahead. Every write checks the list as it stands, and the answer reports any row that turned out differently.\n\n## What an import does to each address\n\nEach row gets exactly one outcome. A row that both changes its status and adds a suppression reports its status outcome, and says it added a suppression too.\n\n| Outcome | When |\n| --- | --- |\n| `create_confirmed` | `subscribed`, with no subscriber and no suppression in Kestrel, and not erased in the file: added as confirmed. |\n| `confirm_pending` | `subscribed`, pending in Kestrel (never confirmed), and not erased in the file: confirmed, and its confirmation link no longer works. |\n| `unchanged` | Already confirmed in Kestrel, or already in the state the row claims. A subscriber who joined through Kestrel keeps their own record. |\n| `mark_unsubscribed` | `unsubscribed`, and confirmed or pending in Kestrel, with no confirmation in Kestrel newer than the row's `unsubscribed_at`: unsubscribed. |\n| `create_unsubscribed` | `unsubscribed`, with no subscriber in Kestrel, and not erased in Kestrel or in the file: recorded as unsubscribed, so the list remembers they left. |\n| `kept_confirmed_newer` | `unsubscribed`, but the reader confirmed in Kestrel after the source's `unsubscribed_at`: their newer action stands. |\n| `kept_unsubscribed` | `subscribed`, but unsubscribed in Kestrel, or pending again after leaving until they confirm in Kestrel themselves. An unsubscribe is never reversed. |\n| `blocked_by_suppression` | `subscribed`, but the address carries a suppression in Kestrel, a do-not-contact marker included: never added or confirmed. Also `unsubscribed` for an address whose suppression in Kestrel is the do-not-contact marker an erasure left, and, for an address erased in the file (its `suppression` is `erased`, which is still added), `subscribed` or `unsubscribed` with no subscriber in Kestrel, or `subscribed` and pending in Kestrel, which stays pending: no subscriber is recorded or confirmed, so an import never brings back an erased person's data. |\n| `suppression_added` | The row carries a suppression and the address has none in Kestrel, or only a do-not-contact marker, and nothing else changes. Applied whatever the row's `status`. |\n| `left_out` | `pending` or `none` with nothing to apply: counted, never confirmed. An import sends no email, so it can't start a confirmation either. |\n| `invalid` | The address isn't valid. |\n| `merged` | A repeat of an address earlier in the file, folded into it. |\n\nA suppression already in Kestrel is never replaced, with one exception: a bounce, a complaint, or a manual suppression replaces a do-not-contact marker left by an erasure, so a known bad address still gets no confirmation. An imported bounce or complaint is kept apart from one Kestrel saw itself, so the list says where each came from.\n\nAnyone can type an address into your subscribe form, which puts a reader who left back to pending until they confirm. An import treats such a reader as unsubscribed, so it never confirms someone who left in Kestrel.\n\n**Repeats of an address** are folded into one row first. Its status is the first of unsubscribed, subscribed, pending, and none that any repeat claims, and its suppression the first of erased, complaint, bounce, and manual. Its opt-in is the weakest claim. It keeps the earliest consent times and the latest unsubscribe and suppression times, and the origin and evidence of the row whose status won.\n\n## How imported subscribers read\n\nA subscriber an import confirmed is **confirmed**, like anyone who confirmed in Kestrel, and gets your posts. How they joined shows beside their state: imported, with the origin and opt-in method the file claimed, and the evidence. That holds even when the file says they confirmed through Kestrel itself. Only a confirmation Kestrel recorded reads as Kestrel's double opt-in, and a subscriber who later confirms in Kestrel becomes Kestrel's own.\n\n## Limits\n\n- **Rows:** up to 10,000 in one import. On the Workers Free plan's limits (`SUBREQUEST_BUDGET` unset), up to 1,000, since Free's 10 ms of CPU a request can't plan and commit more. Set [`SUBREQUEST_BUDGET`](../reference/01-configuration.md#subrequest_budget) on Workers Paid to take 10,000. Split a larger list into several files.\n- **Size:** a request of at most 10 MB, and `evidence` of at most 500 bytes a row.\n- **Database writes on Workers Free:** D1's free plan allows 100,000 rows written a day, and refuses every query past that until midnight UTC. Each new subscriber an import brings in writes 7 rows, and a send writes about 14 a recipient. So one import of 1,000 new subscribers uses about 7% of a day's writes, and about 10 of them use most of a day. On Workers Free, the plan warns when it and the day's earlier imports, by UTC, would use more than 70% of the day, and advises importing the file the next day. A send scheduled for a day imports have written warns in the same way, and advises sending the next day. Neither warning refuses.\n\n## Exporting\n\nThe export reads your whole list out in this format, a page at a time, at `GET /api/subscribers/export`. Each page holds up to 1,000 rows on the Workers Free plan's limits, or 10,000 otherwise, and its `next` value asks for the page after it. Following `next` until it's `null` gives every address exactly once, even if the list changes while you read. An address added or removed partway through may or may not appear. To make one CSV in this format, write the pages' rows under a single header. The dashboard's **Export** button, on the Subscribers screen, does this for you and downloads the whole list as one CSV. In the CSV, a value that starts with `=`, `+`, `-`, or `@` is written with an apostrophe before it, so a spreadsheet shows it as text rather than running it as a formula; an import takes the apostrophe off again. It includes every subscriber with how they joined, their evidence, and their suppression, and every address suppressed with no subscriber behind it, written as `status: none`. A confirmed subscriber is written as `subscribed`. Importing an export into another Kestrel carries the list over: the same states and suppressions, with every confirmation arriving as imported, carrying its original evidence. Pending subscribers are left out on the way in, since an import sends no confirmation.\n";
+var working_with_claude_default = "# Working with Claude\n\nAsk Claude in plain words, the way you'd ask a colleague. It works through the same API as the dashboard, so it can do what you can do there, and nothing more. Everything it changes shows in the dashboard as Claude's.\n\nTo set Claude up, follow [Connect Claude to the API](../guides/01-connect-claude.md). Claude reads these same pages from your Kestrel, so it explains things in the words you see here.\n\n## What to ask Claude\n\n- **Draft or proofread a post.** Give it notes, an outline, or a draft. It saves a new version you can open in the dashboard. If you edited the post meanwhile, its save is refused, and it works from your version or asks you.\n- **Test and schedule a post.** Name the post and when it should go out, and say so if it should be email only. Claude tells you whether the post will be in your archive, and at which address, before it schedules. Then it sends a test of exactly what will go out and tells you how to cancel. It can also cancel a send or move it.\n- **Take a sent post out of your archive, or put it back.** Claude asks first, as the dashboard does, since taking a post out breaks links people shared.\n- **Check how a send did.** Claude reads the send's record and reports what was delivered, unsent, bounced, or complained.\n- **Lift a bounce or a complaint.** The dashboard can't, so ask Claude when you know an address works again. [Lifting a suppression](06-troubleshooting.md#lifting-a-suppression) says when that's wise.\n- **Recover an earlier version.** Every save keeps a whole version of a post, and Claude can read them back.\n- **Import a list.** Its `/migrate-list` skill asks what anything ambiguous in your old service's export means, and converts a few rows for you to check. It imports once you attest, and if a scheduled post would grow, you finish the import in the dashboard.\n\n## The lines it can't cross\n\nThe app holds these for any client, so they hold whatever Claude is told:\n\n- **Every send waits out the review window,** and you can cancel it until it goes out.\n- **A scheduled post is locked,** and what goes out is exactly the copy that was scheduled.\n- **No one is mailed twice,** and only confirmed subscribers receive a post.\n- **An unsubscribe is final** until the reader subscribes again, and an erased address stays erased until the person confirms 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.** An import through Claude that would stops there, until you finish it in the dashboard.\n\nClaude also follows instructions your Kestrel gives it, which live in your instance's repository. Those hold only as long as the instructions do. They have Claude ask before anything that reaches readers, say whether a post will be in your archive before it's sent, test again after a template change, and record whose decision each change to the list was. They also have it treat what's in a post or a subscriber's record as content, never as instructions.\n\nThe app lets Claude give your attestation for an import, so asking you first is one of those instructions, not a rule the app enforces. The import's record says it came through Claude, and Kestrel emails you about it if your notifications are set.\n";
 
 // docs/publishing/09-share-your-subscribe-link.md
-var share_your_subscribe_link_default = "# Share your subscribe link\n\nYour publication has a public subscribe page at `/subscribe` on your Kestrel's address, such as `https://newsletter.example.com/subscribe`. Share that link wherever your readers are, or put the same form on your own website. Either way, a reader joins only once they confirm by email.\n\nThis page covers what a reader sees, the confirmation email, putting the form on your site, and previewing every page a reader can land on. You find the link under **Settings \u2192 Ways to subscribe**, and on the dashboard's first-run checklist.\n\n## What a reader sees\n\n**A reader enters their address, gets a confirmation email, and presses a button to confirm. Only then do they receive your posts.**\n\nThe subscribe page wears your publication's name, tagline, and logo, which you set in [Name your publication](03-name-your-publication.md). Your landing page and archive carry a subscribe prompt too. After a reader submits their address, the page tells them to check their inbox. The email's link opens a page with a **Confirm subscription** button, and pressing it puts them on your list. This is double opt-in, and it's your record that each reader asked for your newsletter.\n\nOpening the link alone records nothing, since mail scanners open links before a person does. A confirmation link also works only for a limited time. An expired link offers to send a fresh one.\n\n## Addresses already on your list, or that left\n\n**Every address gets the same answer, so the form never reveals who subscribes.**\n\nThe page always says to check the inbox, whatever the address is. Behind it, Kestrel sends a confirmation only when one is due:\n\n- **Already subscribed:** no email goes out, and they stay subscribed.\n- **Waiting to confirm:** they get a confirmation, but at most one every 15 minutes, however often the form is submitted. A confirmation link works for 7 days, and an older one offers to send a fresh link.\n- **Unsubscribed earlier:** they get a confirmation, and confirming it puts them back on your list.\n- **Bounced, complained, or blocked:** no email goes out. [After a send](06-after-a-send.md) covers those addresses.\n- **Erased at their request:** they get a confirmation, and confirming lifts the erasure, so they're back on your list.\n\n## The confirmation email\n\n**You can change its words in Settings \u2192 Confirmation email. Its layout and its link are fixed.**\n\nThe section shows the email as a reader gets it. Choose **Edit** to change four things:\n\n- **Subject line**\n- **Message**, the line above the confirm button\n- **Button label**\n- **Reassurance line**, a quiet footer for anyone who didn't sign up. Leave it blank to omit it.\n\nA required field left blank uses Kestrel's default wording, and **Reset to Kestrel default** brings all of it back. Save with the page's save bar.\n\nWhat you can't change keeps every confirmation working. The email always opens with your publication's name and logo, so a reader sees who's asking first. Kestrel adds the confirm link itself, so no edit can leave it out. The confirmation isn't a post, so it doesn't use your email template and has no unsubscribe link. The words on the page the link opens are fixed too, so what a reader agrees to can't be edited away.\n\n## Put the form on your own site\n\n**Copy the form from Settings \u2192 Ways to subscribe \u2192 Embed a form, and paste it into any page you control.**\n\nChoose a look first:\n\n- **Styled** looks like your subscribe page, with its own fonts and colors carried along, so it fits anywhere.\n- **Plain** is bare markup that takes your site's styles, or the browser's own controls where your site has none.\n\nThe section shows the form as it will look beside the HTML that makes it. Choose **Copy HTML**, then paste it into your site. The form heads itself \"Subscribe to\" your publication's name.\n\nA reader who submits it lands on your Kestrel's own check-your-inbox page, and confirms by email as on the subscribe page.\n\n## Preview every reader page\n\n**Settings \u2192 Reader pages shows each page a reader can land on, exactly as they see it, without walking through the steps.**\n\nPick a page from the list: the subscribe form and its check-your-inbox page, the confirm and unsubscribe pages, or your landing page, archive, and a post page. Pages a reader rarely meets, such as an expired link or an archive with no posts yet, are there too. **Desktop** and **Phone** show each at either width. These are samples, so nothing on them subscribes or unsubscribes anyone.\n\n## When signups aren't open yet\n\n**The form takes no addresses until whoever runs your Kestrel connects email.**\n\nUntil then, the subscribe page says the newsletter isn't taking subscribers yet, and the dashboard and Settings say so too. You can still share the link, and it opens once email is connected. [Connect Amazon SES](../get-started/04-ses.md) is that step.\n\nWhoever runs your Kestrel can also limit how often anyone submits the form, which slows down abuse. [Rate-limit the subscribe form](../guides/05-rate-limit.md) covers it.\n\n## Already have a list somewhere else\n\n**Import it instead of asking everyone to sign up again.** Readers who opted in with your old service come with that record of their consent. [Bring your existing list](01-your-list.md) covers importing and exporting.\n\nNext, send your first post: [Scheduling and sending](05-scheduling-and-sending.md).\n";
+var share_your_subscribe_link_default = "# Share your subscribe link\n\nYour publication's subscribe page is at `/subscribe` on your Kestrel's address, such as `https://newsletter.example.com/subscribe`. Copy it from the dashboard's checklist or **Settings \u2192 Ways to subscribe**, and share it wherever your readers are. A reader joins only once they confirm by email.\n\n**Signups open only once an email provider is connected.** Until then, the page says the newsletter isn't taking subscribers yet, and the dashboard says so too. You can share the link anyway, and it opens once email is connected ([Connect Amazon SES](../get-started/04-ses.md)).\n\n## How a reader joins\n\nA reader enters their address, gets a confirmation email, and presses **Confirm subscription** on the page its link opens. Only then do they receive your posts. Opening the link alone records nothing, since mail scanners open links before a person does. This double opt-in is your record that each reader asked for your newsletter.\n\nEvery address gets the same answer, so the form never reveals who subscribes. Behind it, Kestrel sends a confirmation only when one is due:\n\n- **Already subscribed, bounced, complained, or blocked:** no email goes out.\n- **Waiting to confirm:** at most one confirmation every 15 minutes, however often the form is submitted. A link works for 7 days, and an expired one offers a fresh link.\n- **Unsubscribed earlier, or erased at their request:** they get a confirmation, and confirming puts them back on your list.\n\n## The confirmation email\n\nChange its subject, message, button label, and reassurance line under **Settings \u2192 Confirmation email**. Kestrel adds your name, your logo, and the confirm link itself, so no edit can leave them out. The confirmation isn't a post, so it doesn't use your email template.\n\n## Put the form on your own site\n\n**Settings \u2192 Ways to subscribe \u2192 Embed a form** gives you HTML to paste into any page you control. **Styled** looks like your subscribe page, and **Plain** takes your site's own styles. A reader who submits it confirms by email, as on the subscribe page.\n\n**Settings \u2192 Reader pages** shows every page a reader can land on, at desktop and phone widths, without walking through the steps. You can also limit how often anyone submits the form, which slows down abuse ([Rate-limit the subscribe form](../guides/05-rate-limit.md)).\n";
 
 // docs/publishing/10-check-your-setup.md
-var check_your_setup_default = "# Check your setup\n\nBefore your readers get anything, see it arrive yourself, and make sure a problem will reach you without your watching for it. Send yourself a test, subscribe yourself, and set where Kestrel emails you. It's the second step of **Set up your publication** on your dashboard.\n\nThis page covers whether email is connected, what to check in a test, how Kestrel tells you something's wrong, and what changes as your list grows.\n\n## Email is connected\n\nIf nothing on your dashboard says otherwise, it is. While no email provider is connected, Kestrel says so wherever a send would fail. Until your first post, the dashboard's checklist shows **Connect Amazon SES** in place of this step. After that, an amber line on the dashboard reads \"No email provider connected, so nothing can be sent yet.\" The Schedule dialog says the post can't be scheduled yet, and its buttons are unavailable.\n\n**Settings \u2192 Email sender** shows your From address, sending domain, and email provider, read-only. Connecting a provider is for whoever runs your Kestrel, in [Connect Amazon SES](../get-started/04-ses.md) and [Verify it works](../get-started/05-verify.md).\n\n## Send yourself a test\n\nA test shows you exactly what readers get, and you can send one before you write any post. Choose **Template** in the sidebar, then **Send test email**, and send a sample post to your own inboxes. [Name your publication](03-name-your-publication.md) covers the template, and [Write your first post](04-write-a-post.md#test-emails) covers what a test is.\n\nWhen it arrives, look at:\n\n- **The From name and address.** They're what readers see first.\n- **Your logo and name,** as your template prints them.\n- **Where it lands:** the inbox, Promotions, or spam. If it lands in spam, tell whoever runs your Kestrel. [Sending-domain DNS](../reference/02-sending-domain-dns.md) covers what they check.\n- **A reply.** Reply to the test, and check that it reaches your inbox. Kestrel never sees replies, so this depends on [forwarding set up by whoever runs your Kestrel](../get-started/04-ses.md#3-receive-replies-at-your-from-address).\n\n## Subscribe yourself\n\nSubscribing with a personal address shows you what a new reader sees. Use your public subscribe page, at your publication's address followed by `/subscribe`. The confirmation email arrives with your wording. Once you confirm, you appear under **Subscribers** as **Confirmed**. [Share your subscribe link](09-share-your-subscribe-link.md) covers the page and the confirmation email.\n\n## How Kestrel tells you something's wrong\n\nKestrel tells you in three places: your inbox, the dashboard, and the Schedule dialog. Most of the time, none of them says anything.\n\n- **Notifications.** Set your address under **Settings \u2192 Notifications**, in **Send notifications to**, and save. **Send a test notification** checks that one arrives. With no address set, nothing is emailed. [After a send](06-after-a-send.md#notifications) lists what you're told.\n- **The dashboard's health block.** It appears only when something needs attention, and stays until it clears. Red needs you to act, and amber is worth a look.\n- **Warnings when you schedule.** The Schedule dialog warns you before you schedule something that could go wrong. [Scheduling and sending](05-scheduling-and-sending.md#warnings-in-the-schedule-dialog) covers them.\n\nWhoever runs your Kestrel chooses how notifications are sent. [Notifications through Cloudflare's email](../guides/03-notifications.md) covers a way that reaches you even when your email provider refuses your account.\n\n## As your list grows\n\nA growing list meets a few limits, and Kestrel tells you before or when it reaches each one. Raising each is a change for whoever runs your Kestrel, on the plans and accounts they chose, as [Go live](../get-started/06-go-live.md#as-your-list-grows) describes.\n\n- **Your provider's daily sending quota.** A send that hits it waits, and the dashboard shows why. It resumes on its own once the quota frees up, and nobody is mailed twice. Amazon SES reports a spent quota as refusing your account, so its email reaches you only if your notifications go another way ([Notifications](06-after-a-send.md#notifications)).\n- **How long a send takes.** It grows with your list, and depends on your provider's sending rate and the hosting plan whoever runs your Kestrel chose. [Go live](../get-started/06-go-live.md#as-your-list-grows) gives the rates.\n- **Daily database writes on the free hosting plan.** A large send or import can use up the day's writes. Then the whole app stops until midnight UTC. On that plan, Kestrel warns you before a send to more than 5,000 recipients. It also warns you before an import that would use most of the day's writes. Neither warning stops you. [Bring your existing list](01-your-list.md#limits) explains more.\n\nFrom about 5,000 subscribers, it's recommended that whoever runs your Kestrel moves to the paid hosting plan, which has no daily limit on writes.\n\nNext, [Bring your existing list](01-your-list.md).\n";
+var check_your_setup_default = "# Check your setup\n\nBefore your readers get anything, see it arrive yourself, and make sure a problem will reach you without your watching for it. Send yourself a test and reply to it, subscribe yourself, and set where Kestrel emails you.\n\nIf you're bringing a list of more than about 5,000 subscribers, upgrade to Cloudflare's Workers Paid plan before you import it. On the free plan, a large import and a send can use up the day's database writes. Then the app stops working until midnight UTC. [As your list grows](../guides/09-as-your-list-grows.md) walks through the upgrade.\n\n## Send yourself a test\n\nChoose **Template** in the sidebar, then **Send test email**, and send a sample post to your own inboxes. When it arrives, check:\n\n- **The From name and address,** which readers see first. They're set when Kestrel is deployed ([Connect Amazon SES](../get-started/04-ses.md#8-set-the-provider-and-deploy)).\n- **Where it lands:** the inbox, Promotions, or spam. If it lands in spam, check your sending domain's records, as [Sending-domain DNS](../reference/02-sending-domain-dns.md) describes.\n- **A reply.** Reply to the test, and check that it reaches your inbox. Kestrel never sees replies, so this depends on [forwarding your From address](../get-started/04-ses.md#3-receive-replies-at-your-from-address).\n\n## Subscribe yourself\n\nOpen your subscribe page, from the link under **Settings \u2192 Ways to subscribe**, and subscribe with a personal address. Then confirm. You see what a new reader sees, and you then appear under **Subscribers** as **Confirmed**. [Share your subscribe link](09-share-your-subscribe-link.md) covers the page and the confirmation email.\n\n## Set your notifications address\n\nUnder **Settings \u2192 Notifications**, fill in **Send notifications to**, save, and choose **Send a test notification**. Kestrel then emails you when a send finishes or needs you. [Notifications](06-troubleshooting.md#notifications) lists what you're told, and why a second way to send them is worth asking for.\n\n## If email isn't connected\n\nUntil an email provider is connected, nothing can be sent, and the dashboard says so. The checklist shows **Connect Amazon SES** in place of this step, as [Connect Amazon SES](../get-started/04-ses.md) describes. **Settings \u2192 Email sender** shows your From address, sending domain, and provider, read-only.\n\n## As your list grows\n\nA growing list meets your Amazon SES daily sending quota, longer sends, and on Cloudflare's free Workers plan, a cap on daily database writes. Kestrel tells you when you reach each one, and [As your list grows](../guides/09-as-your-list-grows.md) covers raising each.\n\n";
+
+// docs/publishing/11-email-template.md
+var email_template_default = "# Edit your email template\n\nYou write each post in Markdown, and the template is the HTML frame it's sent in, like a layout in a static site generator. `{{ .Post.Body }}` marks where your post goes, and the rest is plain HTML around it. The built-in template works as it comes, so changing it is optional.\n\nTo change it, choose **Template** in the sidebar, edit the HTML, and choose **Save changes**. **Start from example** offers two starting points. **Signed** ends each post with your logo, name, and tagline, and **Plain** has just your post and the footer links.\n\n## What every template needs\n\nKestrel won't save a template without `{{ .Post.Body }}` and `{{ .Email.UnsubscribeURL }}`. Every email has to carry the post and a way to leave. The two **Required** pills above the editor turn green or red as your template gains or loses them.\n\nWrap a part in `{{ if .IsEmail }}` and `{{ end }}` to keep it off each post's public page. The starting templates do this with the unsubscribe link, the View in browser link, and the mailing address.\n\n## Variables\n\nA variable is replaced with its value in each email. Type it exactly as shown, or it renders as empty.\n\n| Variable | What it holds |\n| --- | --- |\n| `{{ .Post.Body }}` | Your post, rendered from Markdown. Required. |\n| `{{ .Post.Subject }}` | The post's subject line. |\n| `{{ .Publication.Name }}` | Your publication's name. |\n| `{{ .Publication.Tagline }}` | Your tagline. |\n| `{{ .Publication.Logo }}` | Your logo as an image, or nothing when no logo is set. |\n| `{{ .Publication.LogoURL }}` | Your logo's address, or empty. |\n| `{{ .Publication.Address }}` | Your mailing address, or empty. |\n| `{{ .Email.SentTo }}` | The address this email was sent to. |\n| `{{ .Email.UnsubscribeURL }}` | This reader's one-click unsubscribe link. Required. |\n| `{{ .Email.ViewInBrowserURL }}` | The post's own web link, which opens its page once it's sent, in your archive or not. |\n\n## Test it\n\n**Send test email** on the **Template** page sends a sample post through your saved template, so you see it in a real inbox. With unsaved edits, the button reads **Save & send test**, since a test always uses the saved template.\n\nA change to the template re-makes the email of every scheduled post, as [Schedule and send](04-write-a-post.md#schedule-and-send) describes.\n";
 
 // docs/publishing/README.md
-var README_default = "# Publishing with Kestrel\n\nThese pages cover writing and sending your newsletter in the dashboard, from naming your publication to what happens after each send. Deploying and running Kestrel itself is covered in [Self-hosting](../README.md).\n\n## Set up your publication\n\nThe steps your dashboard lists until your first post, in the same order.\n\n1. [Name your publication](03-name-your-publication.md)\n1. [Check your setup](10-check-your-setup.md)\n1. [Bring your existing list](01-your-list.md)\n1. [Write your first post](04-write-a-post.md)\n1. [Share your subscribe link](09-share-your-subscribe-link.md)\n\n## Sending\n\nScheduling a post, what happens when it goes out, and the rules every send keeps.\n\n- [Scheduling and sending](05-scheduling-and-sending.md)\n- [After a send](06-after-a-send.md)\n- [Sending rules](02-sending-rules.md)\n\n## More\n\n- [Working with Claude](07-working-with-claude.md)\n- [Subscriber import format](08-import-format.md)\n";
+var README_default = "# Publishing with Kestrel\n\nThese pages get you publishing in the dashboard, and cover the decisions to make before they matter. Deploying and running Kestrel itself is covered in [Self-hosting](../README.md).\n\n## Set up your publication\n\nThe steps to set up a new publication, in the order the dashboard's setup checklist lists them. Once you've started a post, they stay on the dashboard as **Finish setting up** until you publish your first post, one that goes to your subscribers and onto your site. That's the fourth step.\n\n1. [Name your publication](03-name-your-publication.md)\n1. [Check your setup](10-check-your-setup.md)\n1. [Bring your existing list](01-your-list.md)\n1. [Write and send a post](04-write-a-post.md)\n1. [Share your subscribe link](09-share-your-subscribe-link.md)\n\n## Go further\n\nThings you choose to do once you're running.\n\n- [Edit your email template](11-email-template.md)\n- [Working with Claude](07-working-with-claude.md)\n\n## Rules and troubleshooting\n\nWhat the law asks of every send, and what to do when something goes wrong.\n\n- [Sending rules](02-sending-rules.md)\n- [Troubleshooting](06-troubleshooting.md)\n";
 
 // docs/README.md
-var README_default2 = "# Self-hosting Kestrel\n\nThese pages deploy and run your own instance of Kestrel, from an empty repository to a newsletter on your own Cloudflare account. Writing and sending the newsletter is covered in [Publishing](publishing/README.md).\n\n## Get started\n\nFollow these steps, from an empty repository to a live newsletter. Each one ends with a check, so you know it worked before you move on.\n\n1. [Deploy the app](get-started/02-deploy.md)\n1. [Lock the dashboard with Access](get-started/03-access.md)\n1. [Connect Amazon SES](get-started/04-ses.md)\n1. [Verify it works](get-started/05-verify.md)\n1. [Go live](get-started/06-go-live.md)\n\n## Guides\n\nEach one stands on its own. Pick the ones you need.\n\n- [Connect Claude to the API](guides/01-connect-claude.md)\n- [Try Kestrel locally first](guides/08-try-locally.md)\n- [Notifications through Cloudflare's email](guides/03-notifications.md)\n- [Rate-limit the subscribe form](guides/05-rate-limit.md)\n- [Upgrade to a new release](guides/07-upgrade.md)\n\n## Reference\n\nThe detail behind the steps, for when you need it.\n\n- [Configuration](reference/01-configuration.md)\n- [Sending-domain DNS: SPF, DKIM, and DMARC](reference/02-sending-domain-dns.md)\n";
+var README_default2 = "# Self-hosting Kestrel\n\nThese pages cover deploying and running your own Kestrel, from an empty repository to a live newsletter on your Cloudflare account. Writing and sending the newsletter is covered in [Publishing](publishing/README.md). These pages call whoever writes and sends it the publisher, which may be you.\n\n## Get started\n\nFollow these steps, from an empty repository to a live newsletter. Each one ends with a check, so you know it worked before you move on.\n\n1. [Deploy the app](get-started/02-deploy.md)\n1. [Lock the dashboard with Access](get-started/03-access.md)\n1. [Connect Amazon SES](get-started/04-ses.md)\n1. [Verify it works](get-started/05-verify.md)\n1. [Go live](get-started/06-go-live.md)\n\n## Guides\n\nEach one stands on its own. Pick the ones you need.\n\n- [Connect Claude to the API](guides/01-connect-claude.md)\n- [Notifications through Cloudflare's email](guides/03-notifications.md)\n- [Rate-limit the subscribe form](guides/05-rate-limit.md)\n- [As your list grows](guides/09-as-your-list-grows.md)\n- [Upgrade to a new release](guides/07-upgrade.md)\n\n## Reference\n\nThe detail behind the steps, for when you need it.\n\n- [Configuration](reference/01-configuration.md)\n- [Sending-domain DNS: SPF, DKIM, and DMARC](reference/02-sending-domain-dns.md)\n";
 
 // docs/reference/01-configuration.md
-var configuration_default = "# Configuration\n\nEvery deploy-time setting: what it does, its default, and what the app refuses. Each environment's settings live in its block under `env` in `wrangler.jsonc`, and its secrets in Cloudflare.\n\n- **Vars** are public values in the block's `vars`, safe to commit. A change takes effect when you deploy.\n- **Secrets** are stored with `npx wrangler secret put NAME --env production`, and never committed. A secret takes effect as soon as you store it, with no redeploy.\n- **Bindings and triggers** connect the Worker to its database, its image bucket, and its schedule.\n\nIn local development, `npm run dev` reads the top level of `wrangler.jsonc` and `.dev.vars`, which you copy from `.dev.vars.example`. Restart it after you change either.\n\nNone of these can be read or changed from inside the app, by the editor or by Claude. Settings in the editor shows the public ones, read-only.\n\n## Vars\n\n| Var | What it is | Default |\n| --- | --- | --- |\n| `PROVIDER` | the email provider: `ses`, or `fake` for local development | none: no provider connected |\n| `APP_ORIGIN` | the origin the app is served from: scheme and host, no path | required |\n| `ARCHIVE_BASE_PATH` | the path the archive lives under | `/archive` |\n| `FROM_ADDRESS` | the `From:` of every email | required with a real provider |\n| `SENDING_DOMAIN` | the sending domain, shown in Settings | none |\n| `AWS_REGION` | the SES region | `us-east-1` in the template, required with SES |\n| `SES_MAX_SEND_RATE` | your SES account's maximum send rate, in messages a second | `14` |\n| `SUBREQUEST_BUDGET` | how many subrequests one minute's send work may use | `50` |\n| `MIN_LEAD_SECONDS` | the least time every send stays cancelable before it goes out | `300` |\n| `ARCHIVE_ORIGIN` | the origin archive links use, to put the archive on your website | `APP_ORIGIN` |\n| `MEDIA_PUBLIC_BASE` | the base URL images are served from | `APP_ORIGIN` + `/media` |\n| `NOTIFY_FROM` | the sender of notifications through Cloudflare's email | `Kestrel <kestrel@` + the app's hostname + `>` |\n| `ALLOW_FAKE_PROVIDER` | `true` lets `fake` run on a real hostname, for a demo that mails no one on purpose | unset |\n\n### `PROVIDER`\n\nUntil it's set, or while it's empty, the app runs with no provider connected. You can write and preview posts, but everything that would send email is refused: scheduling, sending now, test emails, and the confirmation emails that signups need. The subscribe page says signups aren't open yet, and Settings shows **No email provider connected**. Setting it to `none` means the same. A new instance's `production` block declares it empty, `\"PROVIDER\": \"\"`, so wrangler doesn't warn that the top level's value is missing there. [Connect Amazon SES](../get-started/04-ses.md) changes it to `ses`.\n\n`fake` delivers nothing. It records a send as if every recipient accepted it. Local development runs on it, and names it on purpose in the top level of `wrangler.jsonc`. Never copy it into `production`, whatever wrangler suggests: every subscriber would be recorded as sent the post, and never get it. The app refuses `fake` unless `APP_ORIGIN` is on `localhost` or `127.0.0.1`. A hosted demo that runs `fake` on a real hostname on purpose sets `ALLOW_FAKE_PROVIDER` to `true`, which no other deployment needs, and which no other provider reads.\n\n### `FROM_ADDRESS` and `SENDING_DOMAIN`\n\n`FROM_ADDRESS` is the only address mail is sent from, and the identity your provider authenticates. `SENDING_DOMAIN` is for display: Settings shows it beside the From address. The app never checks that the two match, so set `SENDING_DOMAIN` to the part of `FROM_ADDRESS` after the `@`.\n\nNeither one is your publication's name, tagline, or logo. You set those in the editor, under **Settings \u2192 Publication identity**. Until you do, the From address's display name stands in for the name, and with neither, your emails and reader pages show no name at all.\n\n### `ARCHIVE_BASE_PATH`\n\nEvery post you send carries its archive link, `ARCHIVE_BASE_PATH` followed by the post's slug, and those links are permanent. Changing the prefix later breaks every link already mailed, so pick it before your first send. To keep links from an older install working, set it to the prefix they use, such as `/newsletter`.\n\nA missing leading slash is added, and a trailing slash is dropped.\n\n### `SES_MAX_SEND_RATE`\n\nThe app sends SES one request a second, the most SES takes, and each request carries one second of this rate, up to 50 recipients. Set it to the maximum send rate on your SES **Account dashboard**. To send faster, ask AWS to raise that rate to 50 before you move to Workers Paid: on Workers Free, a rate of 50 sends nearly four times as many recipients a minute as 14, and a higher rate adds nothing there. That's `1` in the sandbox, and whatever AWS grants after that. The default, 14, is a common starting rate, not your account's.\n\nA rate set too high only means SES throttles some requests. Those recipients wait for the next minute, and no one is mailed twice.\n\n### `SUBREQUEST_BUDGET`\n\nCloudflare caps how many subrequests one run of a Worker may make. Database queries and outbound requests both count. It also caps database queries alone: 50 a run on Workers Free, and 1,000 on Workers Paid. Each minute's send work is one run, so a large send goes out over several minutes, each stopping short of both caps.\n\nThis setting is the subrequest cap. The app keeps database queries under theirs on its own.\n\n- **The default, 50,** is the Workers Free limit, and safe on any plan. A minute sends four SES requests: 56 recipients at a send rate of 14, and 200 at a rate of 50 or more.\n- **On Workers Paid,** which allows 10,000, set `\"SUBREQUEST_BUDGET\": \"10000\"`. A minute then sends about 50 SES requests, one a second: about 700 recipients at a rate of 14, and about 2,500 at 50 or more.\n- **If you raised the Worker's own limit** with `limits.subrequests`, you may set this to match.\n\nIt's also how the app tells Workers Free from Workers Paid. At the default, the app runs on Free's limits:\n\n- One import takes up to 1,000 rows, since Free's 10 ms of CPU a request can't plan and commit more. Above it, up to 10,000 ([Import format](../publishing/08-import-format.md#limits)).\n- An export reads 1,000 rows a page. Above it, 10,000.\n- The app warns before a send to more than 5,000 recipients (fewer on a day you've imported), and on an import plan that, with the day's earlier imports, would use most of a day's writes. Either may use up D1's daily allowance of 100,000 rows written, which stops the app until midnight UTC ([As your list grows](../get-started/06-go-live.md#as-your-list-grows)). Neither warning stops you. Above the default, neither appears.\n\nNever set it above your plan's limit. A minute that hits the cap is cut off mid-batch, and the send stalls until a later minute picks it up. A value below 30 is raised to 30, the least a minute needs to send anything and still send a notification.\n\n### `MIN_LEAD_SECONDS`\n\nEvery send stays visible and cancelable for at least this long before it goes out, whether it's scheduled, sent now, or moved. It's the window to catch a mistake, including one in a send Claude prepared.\n\nThe floor is 60, since sends go out from a once-a-minute schedule. The ceiling is 86400, one day. It's the least wait before every send, not a limit on how far ahead you can schedule. It lives in deploy config on purpose, so neither the editor nor Claude can shorten it.\n\n### `ARCHIVE_ORIGIN` and `MEDIA_PUBLIC_BASE`\n\nLeave them unset to keep everything on the app's own hostname.\n\n`ARCHIVE_ORIGIN` points archive links at another origin, such as your website, `https://example.com`. The app doesn't answer there on its own. A Worker route on that domain, such as `example.com/archive*` in the environment's `routes`, sends the archive path to the app. Links already mailed keep working, since the app still answers on its own hostname.\n\n`MEDIA_PUBLIC_BASE` serves images from another base URL, such as a custom domain on the image bucket. The app's own `/media` path sends `Content-Security-Policy: sandbox` and `X-Content-Type-Options: nosniff` with every file, so a file in the bucket never runs as a page. A bucket's custom domain sends neither, so add both with a Response Header Transform Rule on that hostname.\n\n### `NOTIFY_FROM`\n\nUsed only with the `NOTIFY` binding. It must be an address on a domain set up for Cloudflare's email. Without the binding, notifications come from `FROM_ADDRESS`, through your email provider.\n\n## Secrets\n\n| Secret | What it is | Needed for |\n| --- | --- | --- |\n| `ACCESS_TEAM_DOMAIN` | your Zero Trust team domain, such as `your-team.cloudflareaccess.com`; an `https://` or trailing slash is dropped | every deployment |\n| `ACCESS_AUD` | the Access application's audience tag | every deployment |\n| `ACCESS_ALLOWED_EMAILS` | a comma-separated list of the people allowed to sign in | optional |\n| `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | the IAM user's access key | SES |\n| `SNS_TOPIC_ARN` | the SNS topic the SES webhook accepts; it refuses every other topic | SES |\n| `SES_CONFIGURATION_SET` | the configuration set named on every email, so SES reports bounces and complaints; a name SES can't find in the region holds every list send until it's fixed | SES, recommended |\n\n`ACCESS_ALLOWED_EMAILS` applies to people only. A service token, such as the one Claude uses, carries no email, so the Access policy alone decides whether it gets in.\n\nNever set `DEV_AUTH_SECRET` on a deployed environment. It's local development's stand-in for Access, and a deployed instance ignores it anyway. The app honors it only when the environment looks like local development: `PROVIDER` is `fake`, Access isn't set up, and `APP_ORIGIN` is on `localhost` or `127.0.0.1`. A real provider, Access, or a real hostname each turns it off, and Access becomes the only way in.\n\n## Bindings and triggers\n\nWrangler doesn't carry bindings or vars over from the top level of `wrangler.jsonc` to an environment. Each environment's block declares its own.\n\n| Setting | What it is | Default |\n| --- | --- | --- |\n| `name` | the Worker's name, such as `kestrel-production` | required |\n| `routes` | the app's hostname, attached on deploy, and any route on your website | required |\n| `workers_dev`, `preview_urls` | the Worker's `workers.dev` and preview addresses | `false` in the template |\n| `triggers.crons` | the once-a-minute schedule, `* * * * *` | required |\n| `observability` | Workers Logs, where the app's log lines land | on |\n| `d1_databases`, binding `DB` | the database: posts, subscribers, sends, and settings | required |\n| `r2_buckets`, binding `MEDIA` | the bucket for images and your logo | required |\n| `send_email`, binding `NOTIFY` | Cloudflare's email, for notifications | none |\n\n### `routes`, `workers_dev`, and `preview_urls`\n\nThe template turns off the `workers.dev` addresses, so the app answers only on your hostname. That's where your Access application and any rate-limiting rule apply. Each deploy replaces the Worker's routes with the ones in the file, so add a route here, never in the dashboard.\n\n### `triggers.crons`\n\nThe schedule runs every minute. It sends whatever is due, and the notifications about it. Without it, nothing scheduled ever goes out.\n\n### `observability`\n\nEvery invocation is logged, with no sampling. Sampling could drop the one minute that reports a stuck or missed send.\n\n### `NOTIFY`\n\nWhen declared, notifications go through Cloudflare's email instead of your provider, so they still arrive when your provider refuses your account. Local development ignores it, and sends notifications to a stand-in that delivers nothing.\n\n## What the app refuses\n\nThe app checks its configuration on every request. It refuses to run on one that would do the wrong thing quietly:\n\n- `PROVIDER`, when set, must be exactly `ses`, `fake`, or `none`. A misspelling, or `SES`, is refused, never taken for another. `resend`, which earlier releases supported, is refused with a pointer to [Connect Amazon SES](../get-started/04-ses.md#switch-an-instance-that-already-sends).\n- `fake` runs only when `APP_ORIGIN` is on `localhost` or `127.0.0.1`, unless `ALLOW_FAKE_PROVIDER` is `true`. On a real hostname it would open signups whose confirmations go nowhere, and record every send as delivered. With `fake`, `ALLOW_FAKE_PROVIDER`, when set, must be `true`; every other provider ignores it.\n- `APP_ORIGIN` must be a plain `http` or `https` origin, with no path. So must `ARCHIVE_ORIGIN`, when set. `MEDIA_PUBLIC_BASE`, when set, must be a plain `http` or `https` URL, and may have a path. A trailing slash is dropped from each.\n- A real provider needs `FROM_ADDRESS`, and every secret the table marks for it. SES also needs `AWS_REGION`. `FROM_ADDRESS` must then be an email address, optionally with a display name in front, like `Name <address>`.\n- None of `APP_ORIGIN`, `ARCHIVE_ORIGIN`, `MEDIA_PUBLIC_BASE`, `SENDING_DOMAIN`, or `FROM_ADDRESS` may still be on `example.com` or a name under it, the template's placeholder. That holds with no provider connected too, since every link the app builds would name it. Only `fake` allows it.\n- `SUBREQUEST_BUDGET`, `MIN_LEAD_SECONDS`, and `SES_MAX_SEND_RATE` must be whole numbers above zero. `MIN_LEAD_SECONDS` must also be within its bounds. Any other value is refused, never adjusted. The one exception is a `SUBREQUEST_BUDGET` below 30, which is raised to 30.\n- In local development, `SIMULATE_SENDS` must be off (`off`, `0`, `false`, `no`, or empty), `not-connected` to run as a deployment with no email provider yet, or the provider a local send models: `ses` or `generic` (also `1`, `on`, `true`, or `yes`), optionally followed by `:none` for no injected failures or `:realistic`, the default. Case doesn't matter. A deployed instance ignores it.\n- `ACCESS_TEAM_DOMAIN` and `ACCESS_AUD` are set together or not at all. With only one, the app could verify no sign-in and would let no one into the editor, so it refuses and names the missing one. `ACCESS_TEAM_DOMAIN` must be your team's hostname, such as `your-team.cloudflareaccess.com`. An `https://` or `http://` in front and a trailing slash are dropped, but anything else, such as a path or a port, is refused, since it would fail every sign-in.\n\nUntil it's fixed, no sends go out, and each place says what its reader can act on:\n\n- **The editor** shows a page naming the setting, what's wrong with it, and how to fix it, with a link to its section here. Its own Docs tab can't load until then, so the link opens the project's site.\n- **The API**, `/health`, and the webhooks answer `500` with a body naming the variable, such as `{\"error\":\"invalid_config\",\"message\":\u2026,\"variable\":\"APP_ORIGIN\"}`.\n- **The public pages readers see** answer `503` with a page saying the newsletter is temporarily unavailable. It names no setting.\n- **The Worker's log** records it as `config.invalid`.\n";
+var configuration_default = "# Configuration\n\nEvery deploy-time setting: what it does, its default, and what the app refuses. Each environment's settings live in its block under `env` in `wrangler.jsonc`, and its secrets in Cloudflare.\n\n- **Vars** are public values in the block's `vars`, safe to commit. A change takes effect when you deploy.\n- **Secrets** are stored with `npx wrangler secret put NAME --env production`, and never committed. A secret takes effect as soon as you store it, with no redeploy.\n- **Bindings and triggers** connect the Worker to its database, its image bucket, and its schedule.\n\nIn local development, `npm run dev` reads the top level of `wrangler.jsonc` and `.dev.vars`, which you copy from `.dev.vars.example`. Restart it after you change either.\n\nNone of these can be read or changed from inside the app, by the editor or by Claude. Settings in the editor shows the public ones, read-only.\n\n## Vars\n\n| Var | What it is | Default |\n| --- | --- | --- |\n| `PROVIDER` | the email provider: `ses`, or `fake` for local development | none: no provider connected |\n| `APP_ORIGIN` | the origin the app is served from: scheme and host, no path | required |\n| `ARCHIVE_BASE_PATH` | the path the archive lives under | `/archive` |\n| `FROM_ADDRESS` | the `From:` of every email | required with a real provider |\n| `SENDING_DOMAIN` | the sending domain, shown in Settings | none |\n| `AWS_REGION` | the SES region | `us-east-1` in the template, required with SES |\n| `SES_MAX_SEND_RATE` | your SES account's maximum send rate, in messages a second | `14` |\n| `SUBREQUEST_BUDGET` | how many subrequests one minute's send work may use | `50` |\n| `MIN_LEAD_SECONDS` | the least time every send stays cancelable before it goes out | `300` |\n| `ARCHIVE_ORIGIN` | the origin archive links use, to put the archive on your website | `APP_ORIGIN` |\n| `MEDIA_PUBLIC_BASE` | the base URL images are served from | `APP_ORIGIN` + `/media` |\n| `NOTIFY_FROM` | the sender of notifications through Cloudflare's email | `Kestrel <kestrel@` + the app's hostname + `>` |\n| `ALLOW_FAKE_PROVIDER` | `true` lets `fake` run on a real hostname, for a demo that mails no one on purpose | unset |\n\n### `PROVIDER`\n\nUntil it's set, or while it's empty, the app runs with no provider connected. Posts can be written and previewed, but everything that would send email is refused: scheduling, sending now, test emails, and the confirmation emails that signups need. The subscribe page says signups aren't open yet, and Settings shows **No email provider connected**. Setting it to `none` means the same. A new instance's `production` block declares it empty, `\"PROVIDER\": \"\"`, so wrangler doesn't warn that the top level's value is missing there. [Connect Amazon SES](../get-started/04-ses.md) changes it to `ses`.\n\n`fake` delivers nothing. It records a send as if every recipient accepted it. Local development runs on it, and names it on purpose in the top level of `wrangler.jsonc`. Never copy it into `production`, whatever wrangler suggests: every subscriber would be recorded as sent the post, and never get it. The app refuses `fake` unless `APP_ORIGIN` is on `localhost` or `127.0.0.1`. A hosted demo that runs `fake` on a real hostname on purpose sets `ALLOW_FAKE_PROVIDER` to `true`, which no other deployment needs, and which no other provider reads.\n\n### `FROM_ADDRESS` and `SENDING_DOMAIN`\n\n`FROM_ADDRESS` is the only address mail is sent from, and the identity your provider authenticates. `SENDING_DOMAIN` is for display: Settings shows it beside the From address. The app never checks that the two match, so set `SENDING_DOMAIN` to the part of `FROM_ADDRESS` after the `@`.\n\nNeither one is the publication's name, tagline, or logo. You set those in the editor, under **Settings \u2192 Publication identity**. Until you do, the From address's display name stands in for the name, and with neither, the emails and reader pages show no name at all.\n\n### `ARCHIVE_BASE_PATH`\n\nA listed post's archive address is `ARCHIVE_BASE_PATH` followed by the post's slug. Emails link through each post's unlisted link, `/email/<token>` on `APP_ORIGIN`, which forwards to the archive address, so changing the prefix later breaks no email that carries one, only archive addresses people have shared. Emails sent by 1.11 or earlier carry the archive address itself, and changing the prefix breaks those. To keep links from an older install working, set it to the prefix they use, such as `/newsletter`.\n\nA missing leading slash is added, and a trailing slash is dropped.\n\n### `SES_MAX_SEND_RATE`\n\nThe app sends SES one request a second, the most SES takes, and each request carries one second of this rate, up to 50 recipients. Set it to the maximum send rate on your SES **Account dashboard**. To send faster, ask AWS to raise that rate to 50 before you move to Workers Paid: on Workers Free, a rate of 50 sends nearly four times as many recipients a minute as 14, and a higher rate adds nothing there. That's `1` in the sandbox, and whatever AWS grants after that. The default, 14, is a common starting rate, not your account's.\n\nA rate set too high only means SES throttles some requests. Those recipients wait for the next minute, and no one is mailed twice.\n\n### `SUBREQUEST_BUDGET`\n\nCloudflare caps how many subrequests one run of a Worker may make. Database queries and outbound requests both count. It also caps database queries alone: 50 a run on Workers Free, and 1,000 on Workers Paid. Each minute's send work is one run, so a large send goes out over several minutes, each stopping short of both caps.\n\nThis setting is the subrequest cap. The app keeps database queries under theirs on its own.\n\n- **The default, 50,** is the Workers Free limit, and safe on any plan. A minute sends four SES requests: 56 recipients at a send rate of 14, and 200 at a rate of 50 or more.\n- **On Workers Paid,** which allows 10,000, set `\"SUBREQUEST_BUDGET\": \"10000\"`. A minute then sends about 50 SES requests, one a second: about 700 recipients at a rate of 14, and about 2,500 at 50 or more.\n- **If you raised the Worker's own limit** with `limits.subrequests`, you may set this to match.\n\nIt's also how the app tells Workers Free from Workers Paid. At the default, the app runs on Free's limits:\n\n- One import takes up to 1,000 rows, since Free's 10 ms of CPU a request can't plan and commit more. Above it, up to 10,000 ([Limits in detail](../publishing/01-your-list.md#limits-in-detail)).\n- An export reads 1,000 rows a page. Above it, 10,000.\n- The app warns before a send to more than 5,000 recipients (fewer on a day with imports), and on an import plan that, with the day's earlier imports, would use most of a day's writes. Either may use up D1's daily allowance of 100,000 rows written, which stops the app until midnight UTC ([As your list grows](../guides/09-as-your-list-grows.md)). Neither warning stops you. Above the default, neither appears.\n\nNever set it above your plan's limit. A minute that hits the cap is cut off mid-batch, and the send stalls until a later minute picks it up. A value below 30 is raised to 30, the least a minute needs to send anything and still send a notification.\n\n### `MIN_LEAD_SECONDS`\n\nEvery send stays visible and cancelable for at least this long before it goes out, whether it's scheduled, sent now, or moved. It's the window to catch a mistake, including one in a send Claude prepared.\n\nThe floor is 60, since sends go out from a once-a-minute schedule. The ceiling is 86400, one day. It's the least wait before every send, not a limit on how far ahead a post can be scheduled. It lives in deploy config on purpose, so neither the editor nor Claude can shorten it.\n\n### `ARCHIVE_ORIGIN` and `MEDIA_PUBLIC_BASE`\n\nLeave them unset to keep everything on the app's own hostname.\n\n`ARCHIVE_ORIGIN` points archive links at another origin, such as your website, `https://example.com`. The app doesn't answer there on its own. A Worker route on that domain, such as `example.com/archive*` in the environment's `routes`, sends the archive path to the app. Links already mailed keep working, since the app still answers on its own hostname.\n\n`MEDIA_PUBLIC_BASE` serves images from another base URL, such as a custom domain on the image bucket. The app's own `/media` path sends `Content-Security-Policy: sandbox` and `X-Content-Type-Options: nosniff` with every file, so a file in the bucket never runs as a page. A bucket's custom domain sends neither, so add both with a Response Header Transform Rule on that hostname.\n\n### `NOTIFY_FROM`\n\nUsed only with the `NOTIFY` binding. It must be an address on a domain set up for Cloudflare's email. Without the binding, notifications come from `FROM_ADDRESS`, through your email provider.\n\n## Secrets\n\n| Secret | What it is | Needed for |\n| --- | --- | --- |\n| `ACCESS_TEAM_DOMAIN` | your Zero Trust team domain, such as `your-team.cloudflareaccess.com`; an `https://` or trailing slash is dropped | every deployment |\n| `ACCESS_AUD` | the Access application's audience tag | every deployment |\n| `ACCESS_ALLOWED_EMAILS` | a comma-separated list of the people allowed to sign in | optional |\n| `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | the IAM user's access key | SES |\n| `SNS_TOPIC_ARN` | the SNS topic the SES webhook accepts; it refuses every other topic | SES |\n| `SES_CONFIGURATION_SET` | the configuration set named on every email, so SES reports bounces and complaints; a name SES can't find in the region holds every list send until it's fixed | SES, recommended |\n\n`ACCESS_ALLOWED_EMAILS` applies to people only. A service token, such as the one Claude uses, carries no email, so the Access policy alone decides whether it gets in.\n\nNever set `DEV_AUTH_SECRET` on a deployed environment. It's local development's stand-in for Access, and a deployed instance ignores it anyway. The app honors it only when the environment looks like local development: `PROVIDER` is `fake`, Access isn't set up, and `APP_ORIGIN` is on `localhost` or `127.0.0.1`. A real provider, Access, or a real hostname each turns it off, and Access becomes the only way in.\n\n## Bindings and triggers\n\nWrangler doesn't carry bindings or vars over from the top level of `wrangler.jsonc` to an environment. Each environment's block declares its own.\n\n| Setting | What it is | Default |\n| --- | --- | --- |\n| `name` | the Worker's name, such as `kestrel-production` | required |\n| `routes` | the app's hostname, attached on deploy, and any route on your website | required |\n| `workers_dev`, `preview_urls` | the Worker's `workers.dev` and preview addresses | `false` in the template |\n| `triggers.crons` | the once-a-minute schedule, `* * * * *` | required |\n| `observability` | Workers Logs, where the app's log lines land | on |\n| `d1_databases`, binding `DB` | the database: posts, subscribers, sends, and settings | required |\n| `r2_buckets`, binding `MEDIA` | the bucket for images and your logo | required |\n| `send_email`, binding `NOTIFY` | Cloudflare's email, for notifications | none |\n\n### `routes`, `workers_dev`, and `preview_urls`\n\nThe template turns off the `workers.dev` addresses, so the app answers only on your hostname. That's where your Access application and any rate-limiting rule apply. Each deploy replaces the Worker's routes with the ones in the file, so add a route here, never in the dashboard.\n\n### `triggers.crons`\n\nThe schedule runs every minute. It sends whatever is due, and the notifications about it. Without it, nothing scheduled ever goes out.\n\n### `observability`\n\nEvery invocation is logged, with no sampling. Sampling could drop the one minute that reports a stuck or missed send.\n\n### `NOTIFY`\n\nWhen declared, notifications go through Cloudflare's email instead of your provider, so they still arrive when your provider refuses your account. Local development ignores it, and sends notifications to a stand-in that delivers nothing.\n\n## What the app refuses\n\nThe app checks its configuration on every request. It refuses to run on one that would do the wrong thing quietly:\n\n- `PROVIDER`, when set, must be exactly `ses`, `fake`, or `none`. A misspelling, or `SES`, is refused, never taken for another. `resend`, which earlier releases supported, is refused with a pointer to [Connect Amazon SES](../get-started/04-ses.md#switch-an-instance-that-already-sends).\n- `fake` runs only when `APP_ORIGIN` is on `localhost` or `127.0.0.1`, unless `ALLOW_FAKE_PROVIDER` is `true`. On a real hostname it would open signups whose confirmations go nowhere, and record every send as delivered. With `fake`, `ALLOW_FAKE_PROVIDER`, when set, must be `true`; every other provider ignores it.\n- `APP_ORIGIN` must be a plain `http` or `https` origin, with no path. So must `ARCHIVE_ORIGIN`, when set. `MEDIA_PUBLIC_BASE`, when set, must be a plain `http` or `https` URL, and may have a path. A trailing slash is dropped from each.\n- A real provider needs `FROM_ADDRESS`, and every secret the table marks for it. SES also needs `AWS_REGION`. `FROM_ADDRESS` must then be an email address, optionally with a display name in front, like `Name <address>`.\n- None of `APP_ORIGIN`, `ARCHIVE_ORIGIN`, `MEDIA_PUBLIC_BASE`, `SENDING_DOMAIN`, or `FROM_ADDRESS` may still be on `example.com` or a name under it, the template's placeholder. That holds with no provider connected too, since every link the app builds would name it. Only `fake` allows it.\n- `SUBREQUEST_BUDGET`, `MIN_LEAD_SECONDS`, and `SES_MAX_SEND_RATE` must be whole numbers above zero. `MIN_LEAD_SECONDS` must also be within its bounds. Any other value is refused, never adjusted. The one exception is a `SUBREQUEST_BUDGET` below 30, which is raised to 30.\n- In local development, `SIMULATE_SENDS` must be off (`off`, `0`, `false`, `no`, or empty), `not-connected` to run as a deployment with no email provider yet, or the provider a local send models: `ses` or `generic` (also `1`, `on`, `true`, or `yes`), optionally followed by `:none` for no injected failures or `:realistic`, the default. Case doesn't matter. A deployed instance ignores it.\n- `ACCESS_TEAM_DOMAIN` and `ACCESS_AUD` are set together or not at all. With only one, the app could verify no sign-in and would let no one into the editor, so it refuses and names the missing one. `ACCESS_TEAM_DOMAIN` must be your team's hostname, such as `your-team.cloudflareaccess.com`. An `https://` or `http://` in front and a trailing slash are dropped, but anything else, such as a path or a port, is refused, since it would fail every sign-in.\n\nUntil it's fixed, no sends go out, and each place says what its reader can act on:\n\n- **The editor** shows a page naming the setting, what's wrong with it, and how to fix it, with a link to its section here. Its own Docs tab can't load until then, so the link opens the project's site.\n- **The API**, `/health`, and the webhooks answer `500` with a body naming the variable, such as `{\"error\":\"invalid_config\",\"message\":\u2026,\"variable\":\"APP_ORIGIN\"}`.\n- **The public pages readers see** answer `503` with a page saying the newsletter is temporarily unavailable. It names no setting.\n- **The Worker's log** records it as `config.invalid`.\n";
 
 // docs/reference/02-sending-domain-dns.md
-var sending_domain_dns_default = "# Sending-domain DNS: SPF, DKIM, and DMARC\n\nInboxes decide whether to trust your mail by checking records in the DNS of the domain it comes from. This page explains the three checks they run: SPF, DKIM, and DMARC. It covers the records [Connect Amazon SES](../get-started/04-ses.md) has you add, what each proves, how to check them, and when to tighten DMARC.\n\n## Why all three\n\nGmail requires every sender to pass SPF or DKIM. A sender of more than 5,000 messages a day to Gmail must have all three:\n\n- SPF and DKIM, both passing.\n- A DMARC record, with a policy of at least `p=none`.\n- Alignment: the domain in the `From:` header matches the SPF domain or the DKIM domain.\n\nGmail also requires one-click unsubscribe for such senders. Kestrel adds the `List-Unsubscribe` and `List-Unsubscribe-Post` headers to every email, so that part needs nothing from you. [Google's sender guidelines](https://support.google.com/a/answer/81126) list the rest.\n\nA small list may never reach 5,000 a day, but the same checks decide whether mail lands in the inbox. Make sure all three pass from the start.\n\n## Choose your sending name\n\n- **Send from a subdomain.** It's recommended to send from a subdomain such as `send.example.com`, rather than from `example.com` itself. Your apex domain carries the reputation of your regular email, and a newsletter shouldn't put that at risk.\n- **Keep the app's name and the mail's name distinct.** The app and its public pages live at `newsletter.example.com`, and mail comes from `send.example.com`. Avoid `mail.` as the sending name, since mail servers read `mail.example.com` as a host that receives mail.\n\n## The records\n\nEvery record lives in your domain's DNS, `example.com`, under the sending name. In Cloudflare, a record's name leaves off your domain, so `_dmarc.send.example.com` is entered as `_dmarc.send`.\n\nSES generates the DKIM values. Copy them exactly as SES lists them, since they differ by account and region. You write the DMARC record yourself.\n\nSPF needs no record of yours on SES's default path, since it passes for a subdomain of `amazonses.com`. An SPF record, at `bounce.send`, comes only with the optional custom MAIL FROM domain.\n\nEmail Routing adds MX, SPF, and DKIM records at `send` itself, the DKIM one under the selector `cf2024-1`. They're for mail sent *to* your From address, so readers' replies reach you ([Connect Amazon SES](../get-started/04-ses.md#3-receive-replies-at-your-from-address)). They don't affect your sending: inboxes check SES's mail for SPF at its return path, and for DKIM against SES's own keys.\n\n### SPF: authorize the return path\n\nSPF checks the message's return path, the address bounces go back to, not its `From:` header. DMARC passes when SPF or DKIM passes and aligns with the `From:` domain. DKIM aligns, so an aligned SPF is a second check in your favor, not a requirement.\n\nSES uses a subdomain of its own domain, `amazonses.com`, as the return path by default. SPF then passes for it but doesn't align, and DMARC passes through DKIM alone. A custom MAIL FROM domain, such as `bounce.send.example.com`, aligns SPF too. [Connect Amazon SES](../get-started/04-ses.md#4-optional-set-a-custom-mail-from-domain) sets one up, with an MX record that names your region and an SPF record:\n\n```\nbounce.send.example.com.  MX   10 feedback-smtp.us-east-1.amazonses.com.\nbounce.send.example.com.  TXT  \"v=spf1 include:amazonses.com ~all\"\n```\n\nA name holds one SPF record. If one already exists there, add `include:amazonses.com` to it rather than adding a second.\n\n### DKIM: let the provider sign\n\nDKIM signs each message with a key your DNS publishes. An inbox checks the signature to tell the message came from you, unchanged.\n\nSES lists three `CNAME` records, each at `TOKEN._domainkey.send.example.com`. Their targets depend on your region and account, so copy them as SES lists them.\n\nIn Cloudflare, set every `CNAME` for DKIM to **DNS only**, not proxied. SES reports the domain as verified only once the records resolve.\n\n### DMARC: publish a policy and collect reports\n\nDMARC tells an inbox what to do with mail that fails both SPF and DKIM, and asks it to send you reports. It's a `TXT` record at `_dmarc.send.example.com`:\n\n```\n_dmarc.send.example.com.  TXT  \"v=DMARC1; p=none; rua=mailto:dmarc@example.com\"\n```\n\n- **`p=none`** is monitor mode. Inboxes report on failing mail, but deliver it as usual.\n- **`rua`** is where reports go. They arrive as attachments, usually one a day from each inbox provider.\n\nLeave alignment relaxed, the default, with no `aspf=s` or `adkim=s`. With a custom MAIL FROM domain, your return path is a subdomain of your sending name, so strict SPF alignment would fail.\n\nOnce the reports show your sends passing and aligned, tighten the policy to `p=quarantine`, which sends failing mail to spam. Later, tighten it to `p=reject`, which refuses it.\n\n## Verify alignment\n\nA test email proves alignment better than any DNS lookup. Send yourself one, as in [Verify it works](../get-started/05-verify.md#2-check-that-it-passes-authentication), and read its `Authentication-Results` header. In Gmail, open the message's menu, and select **Show original**. Expect:\n\n- `dkim=pass` for `send.example.com`.\n- `dmarc=pass` for `send.example.com`.\n- `spf=pass`. With a custom MAIL FROM domain, its domain is under `send.example.com`. Without one, it's a subdomain of `amazonses.com`. That's expected, and DMARC still passes.\n";
+var sending_domain_dns_default = "# Sending-domain DNS: SPF, DKIM, and DMARC\n\nInboxes decide whether to trust your mail by checking records in the DNS of the domain it comes from. This page explains the three checks they run: SPF, DKIM, and DMARC. It covers the records [Connect Amazon SES](../get-started/04-ses.md) has you add, what each proves, how to check them, and when to tighten DMARC.\n\n## Why all three\n\nGmail requires every sender to pass SPF or DKIM. A sender of more than 5,000 messages a day to Gmail must have all three:\n\n- SPF and DKIM, both passing.\n- A DMARC record, with a policy of at least `p=none`.\n- Alignment: the domain in the `From:` header matches the SPF domain or the DKIM domain.\n\nGmail also requires one-click unsubscribe for such senders. Kestrel adds the `List-Unsubscribe` and `List-Unsubscribe-Post` headers to every email, so that part needs nothing from you. [Google's sender guidelines](https://support.google.com/a/answer/81126) list the rest.\n\nA small list may never reach 5,000 a day, but the same checks decide whether mail lands in the inbox. Make sure all three pass from the start.\n\n## Choose your sending name\n\n- **Send from a subdomain.** It's recommended to send from a subdomain such as `send.example.com`, rather than from `example.com` itself. Your apex domain carries the reputation of your regular email, and a newsletter shouldn't put that at risk.\n- **Keep the app's name and the mail's name distinct.** The app and its public pages live at `newsletter.example.com`, and mail comes from `send.example.com`. Avoid `mail.` as the sending name, since mail servers read `mail.example.com` as a host that receives mail.\n\n## The records\n\nEvery record lives in your domain's DNS, `example.com`, under the sending name. In Cloudflare, a record's name leaves off your domain, so `_dmarc.send.example.com` is entered as `_dmarc.send`.\n\nSES generates the DKIM values. Copy them exactly as SES lists them, since they differ by account and region. You write the DMARC record yourself.\n\nSPF needs no record of yours on SES's default path, since it passes for a subdomain of `amazonses.com`. An SPF record, at `bounce.send`, comes only with the optional custom MAIL FROM domain.\n\nEmail Routing adds MX, SPF, and DKIM records at `send` itself, the DKIM one under the selector `cf2024-1`. They're for mail sent *to* your From address, so readers' replies reach the publisher ([Connect Amazon SES](../get-started/04-ses.md#3-receive-replies-at-your-from-address)). They don't affect your sending: inboxes check SES's mail for SPF at its return path, and for DKIM against SES's own keys.\n\n### SPF: authorize the return path\n\nSPF checks the message's return path, the address bounces go back to, not its `From:` header. DMARC passes when SPF or DKIM passes and aligns with the `From:` domain. DKIM aligns, so an aligned SPF is a second check in your favor, not a requirement.\n\nSES uses a subdomain of its own domain, `amazonses.com`, as the return path by default. SPF then passes for it but doesn't align, and DMARC passes through DKIM alone. A custom MAIL FROM domain, such as `bounce.send.example.com`, aligns SPF too. [Connect Amazon SES](../get-started/04-ses.md#4-optional-set-a-custom-mail-from-domain) sets one up, with an MX record that names your region and an SPF record:\n\n```\nbounce.send.example.com.  MX   10 feedback-smtp.us-east-1.amazonses.com.\nbounce.send.example.com.  TXT  \"v=spf1 include:amazonses.com ~all\"\n```\n\nA name holds one SPF record. If one already exists there, add `include:amazonses.com` to it rather than adding a second.\n\n### DKIM: let the provider sign\n\nDKIM signs each message with a key your DNS publishes. An inbox checks the signature to tell the message came from you, unchanged.\n\nSES lists three `CNAME` records, each at `TOKEN._domainkey.send.example.com`. Their targets depend on your region and account, so copy them as SES lists them.\n\nIn Cloudflare, set every `CNAME` for DKIM to **DNS only**, not proxied. SES reports the domain as verified only once the records resolve.\n\n### DMARC: publish a policy and collect reports\n\nDMARC tells an inbox what to do with mail that fails both SPF and DKIM, and asks it to send you reports. It's a `TXT` record at `_dmarc.send.example.com`:\n\n```\n_dmarc.send.example.com.  TXT  \"v=DMARC1; p=none; rua=mailto:dmarc@example.com\"\n```\n\n- **`p=none`** is monitor mode. Inboxes report on failing mail, but deliver it as usual.\n- **`rua`** is where reports go. They arrive as attachments, usually one a day from each inbox provider.\n\nLeave alignment relaxed, the default, with no `aspf=s` or `adkim=s`. With a custom MAIL FROM domain, your return path is a subdomain of your sending name, so strict SPF alignment would fail.\n\nOnce the reports show your sends passing and aligned, tighten the policy to `p=quarantine`, which sends failing mail to spam. Later, tighten it to `p=reject`, which refuses it.\n\n## Verify alignment\n\nA test email proves alignment better than any DNS lookup. Send yourself one, as in [Verify it works](../get-started/05-verify.md#2-check-that-it-passes-authentication), and read its `Authentication-Results` header. In Gmail, open the message's menu, and select **Show original**. Expect:\n\n- `dkim=pass` for `send.example.com`.\n- `dmarc=pass` for `send.example.com`.\n- `spf=pass`. With a custom MAIL FROM domain, its domain is under `send.example.com`. Without one, it's a subdomain of `amazonses.com`. That's expected, and DMARC still passes.\n";
 
 // shared/docs.ts
 function headingAnchor(text) {
@@ -6500,10 +6923,9 @@ var PAGES = {
   "publishing/02-sending-rules.md": sending_rules_default,
   "publishing/03-name-your-publication.md": name_your_publication_default,
   "publishing/04-write-a-post.md": write_a_post_default,
-  "publishing/05-scheduling-and-sending.md": scheduling_and_sending_default,
-  "publishing/06-after-a-send.md": after_a_send_default,
+  "publishing/06-troubleshooting.md": troubleshooting_default,
   "publishing/07-working-with-claude.md": working_with_claude_default,
-  "publishing/08-import-format.md": import_format_default,
+  "publishing/11-email-template.md": email_template_default,
   "publishing/09-share-your-subscribe-link.md": share_your_subscribe_link_default,
   "publishing/10-check-your-setup.md": check_your_setup_default,
   "get-started/02-deploy.md": deploy_default,
@@ -6515,7 +6937,7 @@ var PAGES = {
   "guides/03-notifications.md": notifications_default,
   "guides/05-rate-limit.md": rate_limit_default,
   "guides/07-upgrade.md": upgrade_default,
-  "guides/08-try-locally.md": try_locally_default,
+  "guides/09-as-your-list-grows.md": as_your_list_grows_default,
   "reference/01-configuration.md": configuration_default,
   "reference/02-sending-domain-dns.md": sending_domain_dns_default
 };
@@ -6656,8 +7078,15 @@ function renderDocs() {
 }
 var MD_LINK = /\]\(([^)\s#:]+\.md)(#[^)\s]*)?\)/g;
 var MD_CODE = /^(```|~~~)[^\n]*\n[\s\S]*?^\1[^\n]*$|`[^`\n]+`/gm;
+var FORMER_SLUGS = /* @__PURE__ */ new Map([
+  ["import-format", "your-list"],
+  ["scheduling-and-sending", "write-a-post"],
+  ["after-a-send", "troubleshooting"],
+  ["try-locally", "deploy"]
+]);
 function docMarkdown(name) {
-  const doc = DOCS.find((d) => d.slug === name);
+  const slug = FORMER_SLUGS.get(name) ?? name;
+  const doc = DOCS.find((d) => d.slug === slug);
   const set = SET_SOURCES.find((s) => s.id === name);
   const from = doc?.path ?? set?.path;
   const markdown2 = doc?.markdown ?? set?.index;
@@ -6692,6 +7121,74 @@ function markdownResponse(body) {
   return new Response(body, { headers: { "content-type": "text/markdown; charset=utf-8" } });
 }
 
+// src/routes/post_settings.ts
+var SLUG_ATTEMPTS = 3;
+function readSettingsBody(body) {
+  const emailOnly = optBoolean(body, "email_only");
+  const slug = optString(body, "slug");
+  const slugAuto = optBoolean(body, "slug_auto");
+  if (slug !== void 0 && slugAuto === true) {
+    throw fieldError("slug", "slug cannot be set while slug_auto is true");
+  }
+  return { emailOnly, slug, slugAuto };
+}
+async function resolveSettings(db, post, body) {
+  const input = { emailOnly: body.emailOnly };
+  if (body.slug === void 0 && body.slugAuto === void 0) {
+    return input;
+  }
+  const fixed = await addressFixed(db, post);
+  if (fixed) {
+    const moves = body.slug !== void 0 && body.slug !== post.slug || body.slugAuto === true;
+    if (moves) {
+      throw slugPermanent(body.slug !== void 0 ? "slug" : "slug_auto", fixed);
+    }
+    return input;
+  }
+  const resolved = await resolveSlug(
+    db,
+    { postId: post.id, slug: post.slug, slugAuto: post.slug_auto, subject: post.subject },
+    { slug: body.slug, slugAuto: body.slugAuto }
+  );
+  if ("refused" in resolved) {
+    throw slugRefusal(resolved.refused);
+  }
+  input.slug = resolved;
+  return input;
+}
+async function applySettings(db, post, body, resolved) {
+  let input = resolved;
+  let outcome;
+  for (let attempt = 1; ; attempt++) {
+    try {
+      outcome = await setPublishing(db, post, input);
+      break;
+    } catch (err) {
+      if (!isSlugCollision(err)) {
+        throw err;
+      }
+      if (body.slug !== void 0 || attempt >= SLUG_ATTEMPTS) {
+        throw slugRefusal("slug_taken");
+      }
+      input = await resolveSettings(db, post, body);
+    }
+  }
+  if (outcome === "missing") {
+    throw notFound("post");
+  }
+  if (outcome === "address_fixed") {
+    throw slugPermanent(body.slug !== void 0 ? "slug" : "slug_auto", "sent");
+  }
+  return outcome === "changed";
+}
+async function addressFixed(db, post) {
+  if (await publishedSendForPost(db, post.id)) {
+    return "sent";
+  }
+  const active = await getActiveSendForPost(db, post.id);
+  return active?.web_link === "archive" ? "linked" : null;
+}
+
 // src/routes/posts.ts
 function author(c) {
   return c.principal?.email ?? c.principal?.kind ?? null;
@@ -6720,6 +7217,11 @@ function baseRevision(c, body) {
   }
   return body.base_revision;
 }
+var UNPUBLISHED = null;
+async function answered(c, post) {
+  const published = await publicationsFor(c.env.DB, [post.id]);
+  return withAddresses(c.config, post, published.get(post.id) ?? null);
+}
 function revisionHeaders(post) {
   return post.current_revision ? { ETag: `"${post.current_revision}"` } : void 0;
 }
@@ -6743,8 +7245,15 @@ async function requireDraft(c) {
 }
 async function createPost2(c) {
   const { input } = await readBody(c, { optional: true });
-  const { post, revision } = await createPost(c.env.DB, input, author(c));
-  const body = { post, revision_id: revision.id };
+  const { post, revision } = await slugGuarded(
+    input,
+    () => createPost(c.env.DB, input, author(c))
+  );
+  const body = {
+    post: withAddresses(c.config, post, UNPUBLISHED),
+    subject_slug_held: await subjectSlugHeld(c.env.DB, post),
+    revision_id: revision.id
+  };
   return json(body, 201, revisionHeaders(post));
 }
 var POST_STATUSES = ["draft", "scheduled", "sent"];
@@ -6773,8 +7282,12 @@ async function listPosts2(c) {
     countPosts(c.env.DB, filter),
     listPosts(c.env.DB, filter, page)
   ]);
+  const published = await publicationsFor(
+    c.env.DB,
+    rows.map((row) => row.id)
+  );
   const body = {
-    posts: rows,
+    posts: rows.map((row) => withAddresses(c.config, row, published.get(row.id) ?? null)),
     page: listPage(total, page),
     cursor: encodeSendCursor({ seq, at: now })
   };
@@ -6789,7 +7302,8 @@ async function getPost2(c) {
   const active = post.status === "scheduled" ? await getActiveSendForPost(c.env.DB, post.id) : null;
   const sent = post.status === "sent" ? await latestSentSendForPost(c.env.DB, post.id) : null;
   const body = {
-    post,
+    post: await answered(c, post),
+    subject_slug_held: await subjectSlugHeld(c.env.DB, post),
     markdown: revision?.markdown ?? "",
     author: revision?.author ?? null,
     // who wrote the current revision — the freshness poll names them
@@ -6810,7 +7324,7 @@ async function updatePost2(c) {
       error: "base_required",
       message: "A save must name the revision it was based on. Read the post, then save with its current_revision as base_revision or If-Match.",
       field: "base_revision",
-      post
+      post: withAddresses(c.config, post, UNPUBLISHED)
     };
     return json(required, 428, revisionHeaders(post));
   }
@@ -6821,12 +7335,21 @@ async function updatePost2(c) {
       message: "This draft changed since you loaded it. Read it again before saving.",
       current_revision: post.current_revision,
       updated_at: post.updated_at,
-      author: current2?.author ?? null
+      author: current2?.author ?? null,
+      post: withAddresses(c.config, post, UNPUBLISHED),
+      markdown: current2?.markdown ?? ""
     };
     return json(stale, 409, revisionHeaders(post));
   }
-  const { post: updated, revision } = await updatePost(c.env.DB, post, body.input, author(c));
-  const saved = { post: updated, revision_id: revision.id };
+  const { post: updated, revision } = await slugGuarded(
+    body.input,
+    () => updatePost(c.env.DB, post, body.input, author(c))
+  );
+  const saved = {
+    post: withAddresses(c.config, updated, UNPUBLISHED),
+    subject_slug_held: await subjectSlugHeld(c.env.DB, updated),
+    revision_id: revision.id
+  };
   return json(saved, 200, revisionHeaders(updated));
 }
 async function deletePost2(c) {
@@ -6875,6 +7398,47 @@ async function getRevision(c) {
     metadata: JSON.parse(rev.metadata)
   });
 }
+var SLUG_ATTEMPTS2 = 3;
+async function slugGuarded(input, write) {
+  for (let attempt = 1; ; attempt++) {
+    try {
+      return await write();
+    } catch (err) {
+      if (err instanceof SlugRefused) {
+        throw slugRefusal(err.code);
+      }
+      if (isSlugCollision(err)) {
+        if (input.slug === void 0 && attempt < SLUG_ATTEMPTS2) {
+          continue;
+        }
+        throw slugRefusal("slug_taken");
+      }
+      throw err;
+    }
+  }
+}
+async function setSettings(c) {
+  const fields = readSettingsBody(await readJsonObject(c));
+  if (fields.emailOnly === void 0 && fields.slug === void 0 && fields.slugAuto === void 0) {
+    throw fieldError(
+      "email_only",
+      "Name what to change: email_only (true for email only, false to list the post in the archive), slug, or slug_auto"
+    );
+  }
+  const post = await getPost(c.env.DB, param(c, "id"));
+  if (!post) {
+    throw notFound("post");
+  }
+  const input = await resolveSettings(c.env.DB, post, fields);
+  const changed = await applySettings(c.env.DB, post, fields, input);
+  const now = changed ? unwrap(await getPost(c.env.DB, post.id), "post") : post;
+  const answer = {
+    post: await answered(c, now),
+    subject_slug_held: await subjectSlugHeld(c.env.DB, now),
+    changed
+  };
+  return json(answer);
+}
 
 // src/routes/images.ts
 var MAX_POST_IMAGE_BYTES = 5 * 1024 * 1024;
@@ -6989,7 +7553,7 @@ function maxImportRows(subrequestBudget) {
   return onFreePlanLimits({ subrequestBudget }) ? {
     maxRows: IMPORT_LIMITS.maxRowsFree,
     // Said to the publisher, who may never have seen Cloudflare: the setting behind it
-    // is the operator's, in the API reference and the import format page.
+    // is the operator's, in the API reference and Bring your existing list's file format.
     reason: `That\u2019s the limit on Cloudflare\u2019s Workers Free plan. Whoever runs your Kestrel can raise it to ${IMPORT_LIMITS.maxRows.toLocaleString("en-US")} rows by moving to Workers Paid.`
   } : { maxRows: IMPORT_LIMITS.maxRows, reason: null };
 }
@@ -7758,6 +8322,20 @@ function sesFromAddress(from) {
 function sesCanAddress(email2) {
   return ASCII_ONLY.test(email2);
 }
+var LOCAL_PART = /^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*$/i;
+var DOMAIN = /^([a-z0-9]([a-z0-9-]*[a-z0-9])?\.)+[a-z0-9]([a-z0-9-]*[a-z0-9])?$/i;
+function sesAddressProblem(email2) {
+  if (!sesCanAddress(email2)) {
+    return "ses can't send to an address with characters outside ASCII";
+  }
+  const at = email2.lastIndexOf("@");
+  const local = email2.slice(0, at);
+  const domain = email2.slice(at + 1);
+  if (at <= 0 || !LOCAL_PART.test(local) || !DOMAIN.test(domain)) {
+    return "ses can't send to this address: it isn't a well-formed address";
+  }
+  return null;
+}
 
 // src/providers/sns.ts
 var SNS_HOST = /^sns\.[a-z0-9-]+\.amazonaws\.com(\.cn)?$/;
@@ -7877,6 +8455,8 @@ function spkiFromPem(pem) {
   }
   throw new Error("PEM has neither a PUBLIC KEY nor a CERTIFICATE");
 }
+var CertUnavailable = class extends Error {
+};
 async function fetchVerifyKey(certUrl, hash) {
   const cacheKey = `${hash}:${certUrl}`;
   const cached = keyCache.get(cacheKey);
@@ -7892,11 +8472,22 @@ async function fetchVerifyKey(certUrl, hash) {
   if (u.protocol !== "https:" || !isSnsHost(u.hostname)) {
     throw new Error(`untrusted SigningCertURL host: ${u.hostname}`);
   }
-  const res = await fetch(certUrl);
+  let res;
+  let pem;
+  try {
+    res = await fetch(certUrl);
+    pem = res.ok ? await res.text() : "";
+  } catch (err) {
+    throw new CertUnavailable(
+      `signing cert fetch failed: ${err instanceof Error ? err.message : String(err)}`
+    );
+  }
+  if (res.status >= 500 || res.status === 429) {
+    throw new CertUnavailable(`signing cert fetch failed: ${res.status}`);
+  }
   if (!res.ok) {
     throw new Error(`signing cert fetch failed: ${res.status}`);
   }
-  const pem = await res.text();
   const key = await crypto.subtle.importKey(
     "spki",
     spkiFromPem(pem),
@@ -7907,25 +8498,39 @@ async function fetchVerifyKey(certUrl, hash) {
   keyCache.set(cacheKey, key);
   return key;
 }
-async function verifySnsSignature(msg) {
-  if (!msg.Signature || !msg.SigningCertURL) {
+function isSnsCertUrl(certUrl) {
+  try {
+    const u = new URL(certUrl);
+    return u.protocol === "https:" && isSnsHost(u.hostname);
+  } catch {
     return false;
   }
+}
+async function verifySnsSignature(msg) {
+  if (typeof msg.Signature !== "string" || !msg.Signature || typeof msg.SigningCertURL !== "string" || !isSnsCertUrl(msg.SigningCertURL)) {
+    return "unsigned";
+  }
   const hash = msg.SignatureVersion === "2" ? "SHA-256" : msg.SignatureVersion === "1" ? "SHA-1" : null;
   if (!hash) {
-    return false;
+    return "unsigned";
   }
   let key;
   try {
     key = await fetchVerifyKey(msg.SigningCertURL, hash);
-  } catch {
-    return false;
+  } catch (err) {
+    return err instanceof CertUnavailable ? "unavailable" : "invalid";
   }
   try {
     const data = new TextEncoder().encode(canonicalString(msg));
-    return await crypto.subtle.verify("RSASSA-PKCS1-v1_5", key, base64ToBytes(msg.Signature), data);
+    const ok = await crypto.subtle.verify(
+      "RSASSA-PKCS1-v1_5",
+      key,
+      base64ToBytes(msg.Signature),
+      data
+    );
+    return ok ? "valid" : "invalid";
   } catch {
-    return false;
+    return "invalid";
   }
 }
 function sesRenderingFailure(messageJson) {
@@ -7996,20 +8601,23 @@ function sesTraits(config) {
 }
 function sesErrorText(status, type, message2) {
   const detail = [type, message2].filter(Boolean).join(": ");
-  return `ses ${status}${detail ? ` ${detail}` : ""}`;
+  return redactCredentials(`ses ${status}${detail ? ` ${detail}` : ""}`);
 }
 function sesEntryErrorText(status, error) {
-  return `ses ${status}${error ? `: ${error}` : ""}`;
+  return redactCredentials(`ses ${status}${error ? `: ${error}` : ""}`);
 }
 function textResponse(body, status) {
   return new Response(body, { status, headers: { "content-type": "text/plain; charset=utf-8" } });
 }
 var ACCOUNT_ERROR_TYPES = /* @__PURE__ */ new Map([
-  // AWS paused the account's sending (it does so on bounce or complaint trouble) or
-  // restricted it for good; either way, until the operator acts in the SES console.
-  ["SendingPausedException", "suspended"],
+  // AWS restricted the account's sending for good, over its sending practices.
   ["AccountSuspendedException", "suspended"],
-  ["MailFromDomainNotVerifiedException", "sender"],
+  // Sending is paused: by AWS under review, or turned off by hand (`sendingPaused` tells a
+  // configuration set's pause apart by SES's words).
+  ["SendingPausedException", "paused"],
+  // SES's API reference says the sending domain isn't verified, its troubleshooting page that
+  // it can't read the custom MAIL FROM domain's MX record; the advice names both.
+  ["MailFromDomainNotVerifiedException", "mail_from"],
   // A resource the request names doesn't exist. Kestrel names only its configuration set
   // (SES_CONFIGURATION_SET), so this is a typo, a set deleted after setup, or the wrong
   // region: the deployment's to fix, and the same for every recipient, so it holds the send
@@ -8017,55 +8625,132 @@ var ACCOUNT_ERROR_TYPES = /* @__PURE__ */ new Map([
   // resource that could be missing, so a 404 then isn't expected, and the advice still points
   // at the one setting that would cause it.
   ["NotFoundException", "configuration"],
-  // The credentials themselves: unknown, wrongly signed, expired, or not permitted (a key
-  // whose policy lacks `ses:SendBulkEmail` among them).
+  // An action SES doesn't know: the request and the endpoint disagree.
+  ["UnknownOperationException", "unsupported"],
+  // A request SES couldn't parse as HTTP is Kestrel's to fix, never a recipient's.
+  ["MalformedHttpRequestException", "unsupported"],
+  // The AWS account isn't signed up for SES, which the key can't change.
+  ["OptInRequired", "opt_in"],
+  // The credentials themselves: unknown, missing, wrongly or incompletely signed, expired, or
+  // not permitted (a key whose policy lacks `ses:SendBulkEmail` among them). AWS's common
+  // errors carry some of these with a 400, which is why the type, not the status, decides; it
+  // names some both with and without the `Exception` suffix, depending on the front end that
+  // answered, so both spellings are here.
   ["UnrecognizedClientException", "credentials"],
   ["InvalidClientTokenId", "credentials"],
+  ["MissingAuthenticationToken", "credentials"],
+  ["MissingAuthenticationTokenException", "credentials"],
   ["SignatureDoesNotMatch", "credentials"],
+  ["IncompleteSignature", "credentials"],
+  ["IncompleteSignatureException", "credentials"],
+  ["InvalidSignatureException", "credentials"],
+  ["RequestExpired", "credentials"],
   ["ExpiredTokenException", "credentials"],
-  ["AccessDeniedException", "credentials"]
+  ["AccessDeniedException", "credentials"],
+  ["NotAuthorized", "credentials"],
+  // The request as a whole is too large: the email itself, the same for every batch of it.
+  ["RequestEntityTooLargeException", "content"]
 ]);
-function classifySesError(status, type, message2 = "", senderUnverified = false) {
+var UNAVAILABLE_ERROR_TYPES = /* @__PURE__ */ new Set(["RequestTimeoutException", "LimitExceededException"]);
+var UNKNOWN_FATE_ERROR_TYPES = /* @__PURE__ */ new Set(["RequestAbortedException"]);
+function sesFateUnknown(status, type) {
+  return status >= 500 || UNKNOWN_FATE_ERROR_TYPES.has(type);
+}
+function unverifiedIdentities(message2) {
+  if (!/not verified/i.test(message2)) {
+    return null;
+  }
+  const list5 = /failed the check in region[^:]*:(.*)$/is.exec(message2)?.[1] ?? "";
+  return list5.split(",").map(
+    (id) => id.trim().replace(/(\.\.\.|…|\.)$/, "").trim().toLowerCase()
+  ).filter(Boolean);
+}
+function isSenderIdentity(identity, from) {
+  const address = bareAddress(from);
+  if (identity.includes("@")) {
+    return identity === address;
+  }
+  const domain = address.slice(address.lastIndexOf("@") + 1);
+  return identity === domain || domain.endsWith(`.${identity}`);
+}
+function verificationCause(message2, from) {
+  const ids = unverifiedIdentities(message2);
+  if (ids === null) {
+    return null;
+  }
+  if (ids.length === 0 || ids.some((id) => isSenderIdentity(id, from))) {
+    return "sender";
+  }
+  return "sandbox";
+}
+function classifySesError(status, type, message2 = "", from = "") {
   const throttled = status === 429 || /throttl|toomany/i.test(type);
-  const cause = ACCOUNT_ERROR_TYPES.get(type) ?? (status === 404 ? "configuration" : void 0) ?? (senderUnverified ? "sender" : throttled && /daily message quota/i.test(message2) ? "quota" : void 0);
-  if (cause || status === 401 || status === 403) {
-    return { reason: "account", cause: cause ?? "credentials" };
+  if ((throttled || type === "LimitExceededException") && /daily (message|sending) quota/i.test(message2)) {
+    return account("quota");
+  }
+  const named = ACCOUNT_ERROR_TYPES.get(type);
+  if (named) {
+    return account(named === "paused" && /configuration set/i.test(message2) ? "set_paused" : named);
+  }
+  if (type === "MessageRejected") {
+    return account(verificationCause(message2, from) ?? "content");
+  }
+  if (status === 404) {
+    return account("configuration");
+  }
+  if (status === 401 || status === 403) {
+    return account("credentials");
   }
   if (throttled) {
-    return { reason: "unavailable", cause: "rate_limit" };
+    return unavailable("rate_limit");
   }
-  if (status >= 500) {
-    return { reason: "unavailable", cause: "outage" };
+  if (status === 408 || UNAVAILABLE_ERROR_TYPES.has(type) || status >= 500) {
+    return unavailable("outage");
   }
   return null;
 }
-var account = (cause) => ({
-  reason: "account",
-  cause
-});
-var unavailable = (cause) => ({
-  reason: "unavailable",
-  cause
-});
+function account(cause) {
+  return { reason: "account", cause };
+}
+function unavailable(cause) {
+  return { reason: "unavailable", cause };
+}
 var ENTRY_HALTS = /* @__PURE__ */ new Map([
   ["ACCOUNT_SUSPENDED", account("suspended")],
-  ["ACCOUNT_SENDING_PAUSED", account("suspended")],
-  ["CONFIGURATION_SET_SENDING_PAUSED", account("suspended")],
-  ["MAIL_FROM_DOMAIN_NOT_VERIFIED", account("sender")],
+  ["ACCOUNT_SENDING_PAUSED", account("paused")],
+  ["CONFIGURATION_SET_SENDING_PAUSED", account("set_paused")],
+  ["MAIL_FROM_DOMAIN_NOT_VERIFIED", account("mail_from")],
   ["ACCOUNT_DAILY_QUOTA_EXCEEDED", account("quota")],
   ["CONFIGURATION_SET_DOES_NOT_EXIST", account("configuration")],
   ["CONFIGURATION_SET_NOT_FOUND", account("configuration")],
-  ["INVALID_SENDING_POOL_NAME", account("configuration")],
-  ["TEMPLATE_DOES_NOT_EXIST", account("configuration")],
-  ["TEMPLATE_NOT_FOUND", account("configuration")],
+  ["INVALID_SENDING_POOL_NAME", account("sending_pool")],
+  ["TEMPLATE_DOES_NOT_EXIST", account("unsupported")],
+  ["TEMPLATE_NOT_FOUND", account("unsupported")],
   ["ACCOUNT_THROTTLED", unavailable("rate_limit")],
   ["TRANSIENT_FAILURE", unavailable("outage")]
 ]);
-function classifySesEntry(status, senderUnverified = false) {
-  return ENTRY_HALTS.get(status) ?? (senderUnverified ? account("sender") : null);
+var ENTRY_RECIPIENT_FAILURES = /* @__PURE__ */ new Map([
+  ["INVALID_PARAMETER", { retryable: false }],
+  ["INVALID_PARAMETER_VALUE", { retryable: false }],
+  ["FAILED", { retryable: true }]
+]);
+function classifySesEntry(status, words = "", from = "") {
+  const halt = ENTRY_HALTS.get(status);
+  if (halt) {
+    return { kind: "halt", halt };
+  }
+  if (status === "MESSAGE_REJECTED") {
+    const verification = verificationCause(words, from);
+    return verification ? { kind: "halt", halt: account(verification) } : { kind: "rejected" };
+  }
+  const own = ENTRY_RECIPIENT_FAILURES.get(status);
+  if (own) {
+    return { kind: "recipient", retryable: own.retryable };
+  }
+  return { kind: "unknown" };
 }
 function worse(a, b) {
-  return !a || a.reason === "unavailable" && b.reason === "account" ? b : a;
+  return !a || haltRank(b) > haltRank(a) ? b : a;
 }
 var SesProvider = class {
   name = "ses";
@@ -8105,15 +8790,11 @@ var SesProvider = class {
     const out = [];
     const sendable = [];
     for (const r of recipients) {
-      if (sesCanAddress(r.email)) {
+      const problem = sesAddressProblem(r.email);
+      if (problem === null) {
         sendable.push(r);
       } else {
-        out.push({
-          email: r.email,
-          accepted: false,
-          retryable: false,
-          error: "ses can't send to an address with characters outside ASCII"
-        });
+        out.push({ email: r.email, accepted: false, retryable: false, error: problem });
       }
     }
     const content = sesTemplateContent(rendered);
@@ -8125,7 +8806,7 @@ var SesProvider = class {
       try {
         answer = opts.purpose === "list" ? await this.sendBulk(content, batch) : await this.sendSingle(content, unwrap(batch[0], "a recipient"));
       } catch (err) {
-        if (opts.purpose === "list" || at === 0 && out.length === 0) {
+        if (opts.purpose === "list" || out.length === 0 && sendable.length === batch.length) {
           throw err;
         }
         const words = err instanceof Error ? err.message : String(err);
@@ -8134,11 +8815,17 @@ var SesProvider = class {
             email: r.email,
             accepted: false,
             retryable: false,
-            error: `ses gave no answer (${words}), so it may have arrived`
+            error: `ses gave no answer (${words})`,
+            unknown: true
           });
         }
         for (const rest of sendable.slice(at + size)) {
-          out.push({ email: rest.email, accepted: false, retryable: true, error: "not sent" });
+          out.push({
+            email: rest.email,
+            accepted: false,
+            retryable: true,
+            error: "not tried, since an earlier request got no answer"
+          });
         }
         break;
       }
@@ -8194,8 +8881,9 @@ var SesProvider = class {
    * (that risks a duplicate, violating I4): it throws, and the send loop leaves its
    * recipients `dispatched` for a human. A request SES never answers is ended the same
    * way: the timeout rejects the fetch, so it throws down that same path. aws4fetch
-   * carries `signal` onto the signed Request. A real HTTP error response is unambiguous:
-   * SES did NOT accept.
+   * carries `signal` onto the signed Request. An HTTP error response says SES did not
+   * accept, except a 5xx or an aborted request (`sesFateUnknown`), which a list send treats
+   * as no answer.
    */
   post(path2, payload) {
     if (this.configurationSet) {
@@ -8208,18 +8896,14 @@ var SesProvider = class {
       signal: AbortSignal.timeout(PROVIDER_REQUEST_TIMEOUT_MS)
     });
   }
-  /** An SES error response as a halt, or as SES's words when it is about the message. */
+  /** An SES error response: its type, its halt, or SES's words when it may be about a
+   *  recipient. */
   async refusal(res) {
     const bodyText = await res.text().catch(() => "");
     const { type, message: message2 } = parseSesError(bodyText, res.headers.get("x-amzn-ErrorType"));
     const error = sesErrorText(res.status, type, message2);
-    const halt = classifySesError(
-      res.status,
-      type,
-      message2,
-      type === "MessageRejected" && this.namesSender(message2)
-    );
-    return { halt: halt ? { ...halt, error } : null, error };
+    const halt = classifySesError(res.status, type, message2, this.from);
+    return { type, halt: halt ? { ...halt, error } : null, error };
   }
   /** One SendEmail with the inline template, for a one-off message to one recipient. */
   async sendSingle(content, r) {
@@ -8264,14 +8948,14 @@ var SesProvider = class {
       }))
     });
     if (!res.ok) {
-      const { halt: halt2, error } = await this.refusal(res);
+      const { type, halt: halt2, error } = await this.refusal(res);
+      if (sesFateUnknown(res.status, type)) {
+        throw new Error(`${error} (SES may have taken the batch before answering)`);
+      }
       if (halt2) {
         return { kind: "halted", halt: halt2 };
       }
-      return {
-        kind: "answered",
-        results: batch.map((r) => ({ email: r.email, accepted: false, retryable: false, error }))
-      };
+      return this.invalidBatch(batch, error);
     }
     let entries = [];
     try {
@@ -8282,6 +8966,8 @@ var SesProvider = class {
     }
     const results = [];
     const heldBack = [];
+    const rejected = [];
+    const own = [];
     let halt = null;
     let short = false;
     for (const [i, r] of batch.entries()) {
@@ -8296,16 +8982,45 @@ var SesProvider = class {
         continue;
       }
       const words = entry2.Error ?? "";
-      const error = sesEntryErrorText(status || "FAILED", words);
-      const entryHalt = classifySesEntry(
-        status,
-        status === "MESSAGE_REJECTED" && this.namesSender(words)
-      );
-      if (entryHalt) {
-        halt = worse(halt, { ...entryHalt, error });
+      const error = sesEntryErrorText(status || "no status", words);
+      const verdict = classifySesEntry(status, words, this.from);
+      if (verdict.kind === "unknown") {
+        log.warn("provider.unrecognized", { provider: "ses", status: status || null, error });
+        short = true;
+      } else if (verdict.kind === "halt") {
+        halt = worse(halt, { ...verdict.halt, error });
         heldBack.push({ email: r.email, error });
-      } else {
+      } else if (namesAddress(words, r.email)) {
         results.push({ email: r.email, accepted: false, retryable: false, error });
+      } else if (verdict.kind === "rejected") {
+        rejected.push({ email: r.email, error });
+      } else {
+        own.push({ email: r.email, error, status, retryable: verdict.retryable });
+      }
+    }
+    const tookAny = results.some((r) => r.accepted);
+    if (rejected.length > 0 && !tookAny) {
+      halt = worse(halt, {
+        reason: "account",
+        cause: "content",
+        error: unwrap(rejected[0], "a rejection").error
+      });
+      heldBack.push(...rejected);
+    } else {
+      for (const r of rejected) {
+        results.push({ email: r.email, accepted: false, retryable: false, error: r.error });
+      }
+    }
+    for (const r of own) {
+      const alike = own.filter((o) => o.status === r.status).length;
+      if (alike > 1 && !tookAny) {
+        halt = worse(halt, {
+          ...r.status === "FAILED" ? unavailable("outage") : account("invalid_request"),
+          error: r.error
+        });
+        heldBack.push({ email: r.email, error: r.error });
+      } else {
+        results.push({ email: r.email, accepted: false, retryable: r.retryable, error: r.error });
       }
     }
     if (halt && !short && !results.some((r) => r.accepted)) {
@@ -8325,11 +9040,32 @@ var SesProvider = class {
     }
     return { kind: "answered", results, halt };
   }
-  /** Whether SES's "not verified" words name this deployment's own sender, which makes a
-   *  rejection the operator's (a sandbox account, or a sending identity that lapsed)
-   *  rather than the recipient's. */
-  namesSender(message2) {
-    return /not verified/i.test(message2) && message2.toLowerCase().includes(bareAddress(this.from));
+  /**
+   * A list batch SES refused as invalid, for a reason that may be one recipient's (a bad
+   * address SES's syntax check refuses) rather than the email's. A batch of one is that
+   * recipient's own, permanently. In a larger batch, a recipient SES's words name is
+   * refused alone and the rest go back to the queue, untouched, for the next request; with
+   * no one named, no one can be blamed, so the send holds for a person to read SES's words
+   * (`invalid_request`), rather than mark a whole batch unsent for one address.
+   */
+  invalidBatch(batch, error) {
+    if (batch.length === 1) {
+      const only = unwrap(batch[0], "a recipient");
+      return {
+        kind: "answered",
+        results: [{ email: only.email, accepted: false, retryable: false, error }]
+      };
+    }
+    const named = batch.filter((r) => namesAddress(error, r.email));
+    if (named.length === 0) {
+      return { kind: "halted", halt: { reason: "account", cause: "invalid_request", error } };
+    }
+    return {
+      kind: "answered",
+      results: batch.map(
+        (r) => named.includes(r) ? { email: r.email, accepted: false, retryable: false, error } : { email: r.email, accepted: false, retryable: true, error: "not sent", held: true }
+      )
+    };
   }
   async parseWebhook(req, env) {
     const expectedTopic = env.SNS_TOPIC_ARN?.trim();
@@ -8342,11 +9078,27 @@ var SesProvider = class {
     } catch {
       return { events: [], response: textResponse("invalid json", 400) };
     }
-    if (!await verifySnsSignature(msg)) {
+    if (typeof msg !== "object" || msg === null) {
+      return { events: [], response: textResponse("invalid json", 400) };
+    }
+    const topic = typeof msg.TopicArn === "string" ? msg.TopicArn.slice(0, 256) : null;
+    const refuse2 = (reason, body) => {
+      log.error("webhook.refused", { provider: "ses", reason, topic, expected: expectedTopic });
+      return { events: [], response: textResponse(body, 403) };
+    };
+    const signature = await verifySnsSignature(msg);
+    if (signature === "unavailable") {
+      log.warn("webhook.cert_unavailable", { provider: "ses", topic });
+      return { events: [], response: textResponse("signing certificate unavailable", 503) };
+    }
+    if (signature === "unsigned") {
       return { events: [], response: textResponse("invalid signature", 403) };
     }
+    if (signature !== "valid") {
+      return refuse2("signature", "invalid signature");
+    }
     if (msg.TopicArn !== expectedTopic) {
-      return { events: [], response: textResponse("unexpected topic", 403) };
+      return refuse2("topic", "unexpected topic");
     }
     switch (msg.Type) {
       case "SubscriptionConfirmation": {
@@ -8407,6 +9159,20 @@ function bareAddress(from) {
   const angle = /<([^>]+)>/.exec(from);
   return (angle?.[1] ?? from).trim().toLowerCase();
 }
+var ADDRESS_CHAR = /[a-z0-9.!#$%&'*+/=?^_`{|}~@-]/i;
+function namesAddress(words, email2) {
+  const text = words.toLowerCase();
+  const target = email2.toLowerCase();
+  for (let at = text.indexOf(target); at >= 0; at = text.indexOf(target, at + 1)) {
+    const before = text[at - 1];
+    const after = text.slice(at + target.length, at + target.length + 2);
+    const endsHere = after === "" || !ADDRESS_CHAR.test(after[0] ?? "") || /^\.(\s|$)/.test(after);
+    if ((before === void 0 || !ADDRESS_CHAR.test(before)) && endsHere) {
+      return true;
+    }
+  }
+  return false;
+}
 
 // src/services/webhook_events.ts
 async function applyDeliveryEvents(db, events) {
@@ -8864,6 +9630,13 @@ async function requestSubscription(c, email2) {
       created
     );
     log.warn("subscribe.confirmation_refused", { provider: c.config.provider, error: sent.error });
+    if (sent.cause === "sandbox") {
+      try {
+        await sandboxNotice(db, now);
+      } catch (err) {
+        log.error("subscribe.failed", { provider: c.config.provider, error: errorText(err) });
+      }
+    }
     return { kind: "failed", delivered: "no", error: sent.error };
   }
   const armed = await armConfirmation(db, subscriber.id, token2, now, subscriber.status);
@@ -8907,7 +9680,7 @@ async function sendConfirmation(c, message2, subscriber, attemptAt) {
     return { delivered: "unknown", error: err instanceof Error ? err.message : String(err) };
   }
   if (result.kind === "halted") {
-    return { delivered: "no", error: result.halt.error };
+    return { delivered: "no", error: result.halt.error, cause: result.halt.cause };
   }
   const [answer] = result.results;
   if (!answer) {
@@ -9266,6 +10039,81 @@ var FakeNotifier = class {
   }
 };
 
+// src/services/test_send.ts
+async function sendTest(provider, email2, recipients, opts, kind) {
+  let answer;
+  try {
+    answer = await provider.sendBatch(email2, recipients, opts);
+  } catch (err) {
+    const error = err instanceof Error ? err.message : String(err);
+    const notSent = noAnswer(error);
+    logNotSent(provider, kind, recipients.length, notSent);
+    return recipients.map((r) => ({ email: r.email, sent: false, notSent }));
+  }
+  const halt = answer.halt;
+  const unknown = [];
+  const refused = [];
+  const answers = perRecipient(answer, recipients).map((r) => {
+    if (r.accepted) {
+      return { email: r.email, sent: true };
+    }
+    const covering = answer.kind === "halted" || r.held ? halt : void 0;
+    const notSent = why(r, covering);
+    if (notSent.may_have_arrived) {
+      unknown.push(notSent);
+    } else if (covering || !r.retryable) {
+      refused.push(notSent);
+    }
+    return { email: r.email, sent: false, notSent };
+  });
+  if (unknown[0]) {
+    logNotSent(provider, kind, unknown.length, unknown[0]);
+  }
+  if (refused[0]) {
+    logNotSent(provider, kind, refused.length, refused[0]);
+  }
+  return answers;
+}
+function noAnswer(error) {
+  return {
+    may_have_arrived: true,
+    error,
+    message: `The provider didn\u2019t answer, so the test may have arrived: ${sentence(error)} Check the inbox before sending it again.`
+  };
+}
+function why(r, halt) {
+  if (r.unknown) {
+    return noAnswer(r.error);
+  }
+  const error = halt?.error ?? r.error;
+  const refused = (message2) => ({ may_have_arrived: false, error, message: message2 });
+  if (halt?.reason === "account") {
+    return refused(
+      `The provider refused it: ${sentence(error)} ${refusalAdvice(halt.cause)} Sending the test again gets the same answer until that is fixed.`
+    );
+  }
+  if (halt) {
+    return refused(
+      `The provider can\u2019t take mail right now: ${sentence(error)} Send the test again in a few minutes.`
+    );
+  }
+  if (r.retryable) {
+    return refused(`It wasn\u2019t sent: ${sentence(error)} Send the test again to try it.`);
+  }
+  return refused(
+    `The provider refused it: ${sentence(error)} Sending to this address again gets the same answer until what the provider names is fixed.`
+  );
+}
+function logNotSent(provider, kind, count, first) {
+  log.warn(first.may_have_arrived ? "test.unknown" : "test.refused", {
+    provider: provider.name,
+    test: kind.test,
+    postId: kind.postId,
+    count,
+    error: first.error
+  });
+}
+
 // src/routes/render_actions.ts
 async function loadRenderInput(c) {
   const post = await getPost(c.env.DB, param(c, "id"));
@@ -9289,7 +10137,9 @@ async function loadPostEmail(c) {
     return {
       input,
       email: { subject: send.subject, html: send.rendered_html, text: send.rendered_text },
-      warnings: [],
+      // What the render said when it froze this copy, kept with it: the copy is what goes
+      // out, so a test of it reports what it found (SPEC §5).
+      warnings: renderWarnings(send),
       frozen: { id: send.id },
       dateMs: send.started_at ?? send.fire_at
     };
@@ -9297,7 +10147,7 @@ async function loadPostEmail(c) {
   const result = await render(input, c.config, await loadBranding(c));
   return { input, email: result, warnings: result.warnings, frozen: null, dateMs: Date.now() };
 }
-function postPage(html) {
+function postPage2(html) {
   return new Response(html, {
     headers: {
       ...POST_PAGE_SECURITY_HEADERS,
@@ -9324,11 +10174,11 @@ async function previewPage(c) {
     ".Email.UnsubscribeURL": testUnsubscribeUrl(c.config),
     ".Email.SentTo": ""
   }).html;
-  return postPage(html);
+  return postPage2(html);
 }
 async function webPage(c) {
   const { email: email2, dateMs } = await loadPostEmail(c);
-  return postPage(
+  return postPage2(
     webVersion(email2.html, {
       config: c.config,
       identity: await readerIdentity(c, c.config),
@@ -9351,19 +10201,24 @@ async function test(c) {
   const provider = getProvider(c.config, c.env);
   const unsubscribeUrl = testUnsubscribeUrl(c.config);
   const recipients = [{ email: to, unsubscribeUrl }];
-  const [res] = perRecipient(
-    await provider.sendBatch(email2, recipients, {
+  const [res] = await sendTest(
+    provider,
+    email2,
+    recipients,
+    {
       purpose: "test",
       tag: `test-${input.post.id}`,
       batchKey: `test-${input.post.id}-${crypto.randomUUID()}`
-    }),
-    recipients
+    },
+    { test: "post", postId: input.post.id }
   );
-  if (frozen && res?.accepted === true) {
+  const sent = res?.sent === true;
+  if (frozen && sent) {
     await markTested(c.env.DB, frozen.id, readAt, Date.now());
   }
   const result = {
-    sent: res?.accepted === true,
+    sent,
+    not_sent: res && !res.sent ? res.notSent : null,
     provider: provider.name,
     to,
     subject: email2.subject,
@@ -9395,8 +10250,11 @@ function sampleRenderInput(subject = TEMPLATE_TEST_SUBJECT) {
     id: "sample",
     slug: "sample-post",
     slug_auto: false,
+    // No post has this token, so the sample's "view in browser" opens "Nothing here yet".
+    unlisted_token: "sample",
     subject,
     status: "draft",
+    email_only: false,
     current_revision: "sample-rev",
     created_at: now,
     updated_at: now
@@ -9464,19 +10322,19 @@ async function templateTest(c) {
   const unsubscribeUrl = testUnsubscribeUrl(c.config);
   const testId = `template-test-${crypto.randomUUID()}`;
   const batch = recipients.map((email2) => ({ email: email2, unsubscribeUrl }));
-  const results = perRecipient(
-    await provider.sendBatch(result, batch, {
-      purpose: "test",
-      tag: testId,
-      batchKey: testId
-    }),
-    batch
+  const answers = await sendTest(
+    provider,
+    result,
+    batch,
+    { purpose: "test", tag: testId, batchKey: testId },
+    { test: "template" }
   );
-  const failed = results.filter((r) => !r.accepted).map((r) => r.email);
+  const notSent = answers.flatMap((a) => a.sent ? [] : [{ email: a.email, ...a.notSent }]);
   const report = {
-    sent: results.filter((r) => r.accepted).length,
+    sent: answers.length - notSent.length,
     total: recipients.length,
-    failed,
+    failed: notSent.map((n) => n.email),
+    not_sent: notSent,
     provider: provider.name,
     recipients,
     subject: result.subject,
@@ -9646,45 +10504,56 @@ async function schedule(c) {
   }
   const body = await readJsonObject(c);
   rejectStrayTemplateChoice(body);
+  const fields = readSettingsBody(body);
   requireConnectedProvider(c.config);
   const fireAt = parseFutureFireAt(body.fire_at, c.config.minLeadMs);
-  const send = await freeze(c.env, c.config, post, fireAt);
-  const frozen = unwrap(await viewWithCursor(c.env, send.id), "send");
-  return json(frozen, 201);
+  const settings = await resolveSettings(c.env.DB, post, fields);
+  const send = await freeze(c.env, c.config, post, fireAt, settings);
+  return json(await frozenAnswer(c, send), 201);
 }
 async function sendNow(c) {
   const post = await getPost(c.env.DB, param(c, "id"));
   if (!post) {
     throw notFound("post");
   }
-  rejectStrayTemplateChoice(await readJsonObject(c, { optional: true }));
+  const body = await readJsonObject(c, { optional: true });
+  rejectStrayTemplateChoice(body);
+  const fields = readSettingsBody(body);
   const active = await getActiveSendForPost(c.env.DB, post.id);
   if (active) {
-    return repeatAnswer(c, active.id);
+    return repeatAnswer(c, active, fields);
   }
   requireConnectedProvider(c.config);
   const now = Date.now();
   const fireAt = acceptFireAt(now + c.config.minLeadMs, c.config.minLeadMs, { now });
+  const settings = await resolveSettings(c.env.DB, post, fields);
   let send;
   try {
-    send = await freeze(c.env, c.config, post, fireAt);
+    send = await freeze(c.env, c.config, post, fireAt, settings);
   } catch (err) {
     if (err instanceof HttpError && err.code === "active_send_exists") {
       const winner = await getActiveSendForPost(c.env.DB, post.id);
       if (winner) {
-        return repeatAnswer(c, winner.id);
+        return repeatAnswer(c, winner, fields);
       }
     }
     throw err;
   }
-  const frozen = unwrap(await viewWithCursor(c.env, send.id), "send");
-  return json(frozen, 201);
+  return json(await frozenAnswer(c, send), 201);
 }
-async function repeatAnswer(c, sendId) {
-  const repeat = {
-    ...unwrap(await viewWithCursor(c.env, sendId), "send"),
-    idempotent: true
+async function frozenAnswer(c, send) {
+  return {
+    ...unwrap(await viewWithCursor(c.env, send.id), "send"),
+    warnings: renderWarnings(send)
   };
+}
+async function repeatAnswer(c, send, fields) {
+  const post = unwrap(await getPost(c.env.DB, param(c, "id")), "post");
+  const differs = fields.emailOnly !== void 0 && fields.emailOnly !== post.email_only || fields.slug !== void 0 && fields.slug !== post.slug || fields.slugAuto !== void 0 && fields.slugAuto !== post.slug_auto;
+  if (differs) {
+    throw await activeSendExists(c.env, send);
+  }
+  const repeat = { ...await frozenAnswer(c, send), idempotent: true };
   return json(repeat);
 }
 
@@ -9852,7 +10721,11 @@ async function feed(c) {
     now,
     since,
     now - SETTLE_FOLLOW_MS,
-    { missedMs: MISSED_THRESHOLD_MS, stuckMs: STUCK_THRESHOLD_MS },
+    {
+      missedMs: MISSED_THRESHOLD_MS,
+      stuckMs: STUCK_THRESHOLD_MS,
+      noReceiptsMs: NO_RECEIPTS_AFTER_MS
+    },
     limit,
     now - BOUNCE_SPIKE_RECENT_MS
   );
@@ -9968,16 +10841,28 @@ async function cancel2(c) {
 }
 async function reschedule2(c) {
   const body = await readJsonObject(c);
+  rejectSettingsFields(body);
   const fireAt = parseFireAt(body.fire_at);
   const id = param(c, "id");
   const { changed } = await reschedule(c.env, id, fireAt, c.config.minLeadMs);
   const response = { ...await answerWith(c, id), changed };
   return json(response);
 }
+function rejectSettingsFields(body) {
+  for (const field of ["email_only", "slug", "slug_auto"]) {
+    if (field in body) {
+      throw fieldError(
+        field,
+        `${field} is not a field of a reschedule, which moves only the send time: change a post\u2019s settings with PUT /api/posts/:id/settings`
+      );
+    }
+  }
+}
 async function resolve(c) {
   const request = await readJsonObject(c);
   const outcome = oneOf(request, "resolution", ["unsent", "accepted"]);
-  const actor = c.principal?.email ?? "service";
+  const principal = unwrap(c.principal, "principal");
+  const actor = principal.email ?? (principal.tokenId ? `service ${principal.tokenId}` : "service");
   const id = param(c, "id");
   const { resolved, completed } = await resolveStuckSend(c.env, id, outcome, actor);
   const body = { ...await answerWith(c, id), resolved, completed };
@@ -10093,7 +10978,18 @@ function composeNotification(n, config) {
           [
             `No email provider is connected to this deployment, so ${title} is held where it is.`,
             refusalAdvice(n.halt_cause),
-            "No one has been marked unsent. The send keeps trying, at most an hour apart, and goes out at the first try after a provider is connected, mailing no one twice."
+            "No one has been marked unsent because of this. The send keeps trying, at most an hour apart, and goes out at the first try after a provider is connected, mailing no one twice. Any other post that comes due meanwhile waits with it, and you are not told again."
+          ],
+          link
+        );
+      }
+      if (isSendOwnHalt(n.halt_cause)) {
+        return message(
+          `Problem with ${title}: the provider is refusing it`,
+          [
+            `The email provider is refusing ${title} itself, so it is paused where it is. The provider said: ${n.halt_error || "no detail given"}`,
+            refusalAdvice(n.halt_cause),
+            "No one has been marked unsent because of this. The send keeps trying, at most an hour apart, mailing no one twice. Other posts go out as usual."
           ],
           link
         );
@@ -10103,16 +10999,16 @@ function composeNotification(n, config) {
         [
           `The email provider is refusing this account, so ${title} is paused where it is. The provider said: ${n.halt_error || "no detail given"}`,
           refusalAdvice(n.halt_cause),
-          "No one has been marked unsent. The send keeps trying, at most an hour apart, and resumes on its own at the next try after the account is fixed, mailing no one twice."
+          "No one has been marked unsent because of this. The send keeps trying, at most an hour apart, and resumes on its own at the next try after the account is fixed, mailing no one twice. Any other post that comes due meanwhile waits with it, and you are not told again."
         ],
         link
       );
     case "stuck":
       return message(
-        `Problem with ${title}: still sending after ${minutes2(STUCK_THRESHOLD_MS)} minutes`,
+        `Problem with ${title}: nothing has gone out for ${minutes2(STUCK_THRESHOLD_MS)} minutes`,
         [
-          `${title} started sending${n.started_at ? ` at ${when(n.started_at)}` : ""} and is still going: ${n.c_pending + n.c_in_flight} recipients have not been sent yet.`,
-          "It keeps retrying on its own. If it stays like this, check the provider's status and the send's page."
+          `${title} has handed off no one since ${when(n.progress_at ?? n.started_at ?? n.episode)}, with no retry or provider problem to explain it: ${n.c_pending + n.c_in_flight} recipients have not been sent yet.`,
+          "The sweep that sends may have stopped or keep failing on this send, or another send may be taking every minute's sending allowance. Check the send's page and the app's logs. It picks up where it stopped, mailing no one twice."
         ],
         link
       );
@@ -10165,6 +11061,17 @@ function sampleNotification(config) {
     dashboardLink(config.appOrigin, "/settings")
   );
 }
+function composeSandboxNotification(config) {
+  return message(
+    "A signup's confirmation was refused: SES is still in the sandbox",
+    [
+      "Someone signed up, and Amazon SES refused to send their confirmation email, because the SES account is still in the sandbox, which mails only addresses verified in SES. They were told a link is on its way, so they may try again.",
+      refusalAdvice("sandbox"),
+      "Until then, every signup from an address not verified in SES is refused the same way, and a post reaches only verified addresses. You are told at most once a day."
+    ],
+    dashboardLink(config.appOrigin, "/subscribers")
+  );
+}
 
 // src/send/remake.ts
 function insideLead(scheduled, minLeadMs, now) {
@@ -10467,9 +11374,9 @@ async function deleteLogo(c) {
 }
 function readPatch(o) {
   const patch = {};
-  const testRecipients = optStringList(o, "testRecipients");
-  if (testRecipients !== void 0) {
-    patch.testRecipients = testRecipients;
+  const testRecipients2 = optStringList(o, "testRecipients");
+  if (testRecipients2 !== void 0) {
+    patch.testRecipients = testRecipients2;
   }
   const p = optObject(o, "publication");
   if (p !== void 0) {
@@ -10714,7 +11621,7 @@ function createRouter({
 }) {
   const devOnly = (...defs) => devMode ? defs : [];
   const lead = `${formatLead(minLeadMs)} on this deployment (\`deployment.minLeadMs\` in \`GET /api/settings\`); a deployment sets it with \`MIN_LEAD_SECONDS\`, never below ${formatLead(MIN_LEAD_FLOOR_MS)}`;
-  const conditionsText = `\`conditions\` is what is wrong with the send, or worth knowing, now (SPEC \xA78, \xA712), derived by the server from the send and the same on every route, most severe first: \`missed\` (still scheduled ${MISSED_THRESHOLD_MS / 6e4} minutes past its fire time: the sweep is not running), \`stuck\` (still sending ${STUCK_THRESHOLD_MS / 6e4} minutes after it started, whatever the cause), \`wedged\` (\`count\` recipients whose delivery is unknown, settled by Resolve), \`refused\` (the provider refusing the account, with its \`cause\`, its own words as \`error\`, the \`advice\` for the fix, which is outside this API, and \`retry_at\`; the send resumes on its own once the account is fixed, having consumed no one), \`provider_unavailable\` (an outage or a rate limit, retried on its own at \`retry_at\`), \`bounce_spike\` (a send finished within ${BOUNCE_SPIKE_RECENT_MS / 864e5} days whose confirmed bounces reached ${BOUNCE_SPIKE_RATE * 100}% of its audience at fire, at least ${BOUNCE_SPIKE_MIN}; \`bounced\` and \`rate\`), \`remade\` (a template or identity change re-made the scheduled email after its last test, \`tested_at\`; a test of the post clears it), and \`daily_writes\` (on the Workers Free plan's limits, a scheduled send to more than ${DAILY_WRITES_SEND_RECIPIENTS.toLocaleString("en-US")} recipients, or to fewer when imports already wrote on the UTC day it fires, which may spend D1's daily allowance of written rows and stop the instance until midnight UTC; \`recipients\`; a warning, never a refusal). Each has a \`severity\` (\`action\`: a person must act; \`warn\`: worth a look; \`info\`), \`since\` (null when the record does not say), a \`message\` to show or relay as it stands, and the \`action\` that settles it, if any. \`actions\` is exactly what the server would accept on the send now, each \`{name, method, path}\`: \`cancel\` and \`reschedule\` while it is scheduled and its fire time is still ahead, \`resolve\` while it is wedged.`;
+  const conditionsText = `\`conditions\` is what is wrong with the send, or worth knowing, now (SPEC \xA78, \xA712), derived by the server from the send and the same on every route, most severe first: \`missed\` (still scheduled ${MISSED_THRESHOLD_MS / 6e4} minutes past its fire time: the sweep is not running), \`stuck\` (in flight too long: no recipient handed off for ${STUCK_THRESHOLD_MS / 6e4} minutes and nothing to explain it, since a halt explains the wait until its \`retry_at\` and a wedged send waits for Resolve; a send that keeps handing off is never stuck, however long it takes), \`wedged\` (\`count\` recipients whose delivery is unknown, settled by Resolve), \`refused\` (the provider refusing the account, or this send's own email, with its \`cause\`, its own words as \`error\`, the \`advice\` for the fix, which is outside this API, and \`retry_at\`; the send resumes on its own once the account is fixed, having consumed no one), \`provider_unavailable\` (an outage or a rate limit, retried on its own at \`retry_at\`; \`warn\` rather than \`info\` for a rate limit that has refused the first request of ${SELF_THROTTLE_HALTS} retries in a row, which the deployment's SES_MAX_SEND_RATE causes, and its message says so), \`bounce_spike\` (a send finished within ${BOUNCE_SPIKE_RECENT_MS / 864e5} days whose confirmed bounces reached ${BOUNCE_SPIKE_RATE * 100}% of its audience at fire, at least ${BOUNCE_SPIKE_MIN}; \`bounced\` and \`rate\`), \`no_receipts\` (a send finished within ${BOUNCE_SPIKE_RECENT_MS / 864e5} days, ${NO_RECEIPTS_AFTER_MS / 6e4} minutes or more after its dispatch finished, with not one delivery, bounce, or complaint receipt for the \`accepted\` recipients the provider took: the provider's events may not be reaching the webhook, so bounces and complaints suppress no one), \`remade\` (a template or identity change re-made the scheduled email after its last test, \`tested_at\`; a test of the post clears it), and \`daily_writes\` (on the Workers Free plan's limits, a scheduled send to more than ${DAILY_WRITES_SEND_RECIPIENTS.toLocaleString("en-US")} recipients, or to fewer when imports already wrote on the UTC day it fires, which may spend D1's daily allowance of written rows and stop the instance until midnight UTC; \`recipients\`; a warning, never a refusal). Each has a \`severity\` (\`action\`: a person must act; \`warn\`: worth a look; \`info\`), \`since\` (null when the record does not say), a \`message\` to show or relay as it stands, and the \`action\` that settles it, if any. \`actions\` is exactly what the server would accept on the send now, each \`{name, method, path}\`: \`cancel\` and \`reschedule\` while it is scheduled and its fire time is still ahead, \`resolve\` while it is wedged.`;
   const notConnected = "Refused with 409 `provider_not_connected` while no email provider is connected (SPEC \xA79), since nothing can be sent.";
   const actionText = "An act carries no precondition on the send you read: it applies to the send as it stands, within the rules above, and the answer shows the result. An `If-Match` header is ignored. Every refusal carries the send as it stands in `send`, in the `GET /api/sends` row shape.";
   const sendExample = (over = {}) => ({
@@ -10722,6 +11629,7 @@ function createRouter({
     post_id: "p_abc123",
     subject: "Spring migration",
     status: "sending",
+    email_only: false,
     rev: 57,
     as_of: 176846761e4,
     fire_at: 17684676e5,
@@ -10803,10 +11711,10 @@ function createRouter({
       path: "/api/whoami",
       access: "admin",
       resource: "system",
-      summary: "The authenticated principal and the auth mode: how this request signed in (access or dev).",
+      summary: "The authenticated principal and the auth mode: how this request signed in (access or dev). A service token's principal carries its Client ID as `tokenId`.",
       handler: (c) => {
-        const { kind, email: email2, via } = unwrap(c.principal, "principal");
-        return json({ principal: { kind, email: email2 }, auth: { mode: via } });
+        const { kind, email: email2, tokenId, via } = unwrap(c.principal, "principal");
+        return json({ principal: { kind, email: email2, tokenId }, auth: { mode: via } });
       }
     },
     {
@@ -10979,13 +11887,14 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "settings",
       summary: "Send a sample post through the saved email template, to `to` or the default recipients (I5).",
-      description: `Renders the stored template, never unsaved editor content; saving first is the client's job, and that save may need the re-make acknowledgement (see \`PUT /api/settings\`). The answer names the recipients the provider didn't accept in \`failed\`, so a client can offer exactly those again and no one gets a second copy. ${notConnected}`,
+      description: `Renders the stored template, never unsaved editor content; saving first is the client's job, and that save may need the re-make acknowledgement (see \`PUT /api/settings\`). The answer names the recipients the provider didn't accept in \`failed\`, so a client can offer exactly those again and no one gets a second copy, and says why for each in \`not_sent\`, in the same order (see \`POST /api/posts/:id/test\`). ${notConnected}`,
       example: {
         request: { to: "you@example.com" },
         response: {
           sent: 1,
           total: 1,
           failed: [],
+          not_sent: [],
           provider: "fake",
           subject: "Template test \u2014 \u2026"
         }
@@ -11019,10 +11928,22 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "posts",
       summary: "Create a draft post. Its slug follows the subject (`slug_auto: true`) unless you send a `slug`, which sets it by hand.",
+      description: "The post is made with its unlisted link, `unlisted_url` (`<app origin>/email/<unlisted_token>`), which every test and send of it carries as view-in-browser and which never changes (SPEC \xA75). Every post a route answers carries both its addresses, absolute: `unlisted_url`, and `archive_url`, where a listed post is published once its send starts, whether or not it shows anything yet. Beside them, `published_at` is when the post's send started (null before), and `archive_live` whether `archive_url` shows the post now. A reader can see the post at `archive_url` when `archive_live`, otherwise at `unlisted_url` once `published_at` is set; which to share is the publisher's call. `status` stays `scheduled` while the send is going out, so read `published_at`, not `status`, for whether a post is public. The slug is the post's archive address, unique among all posts, drafts included (SPEC \xA74). A slug sent by hand must be lowercase letters and numbers with single hyphens, a 400 `slug_invalid` otherwise, and no other post's, a 409 `slug_taken` otherwise. A slug that follows the subject takes the subject's slug, or the first free number (`-2`) when another post holds it, and `subject_slug_held` in the answer names the slug it couldn't take. That field is not a refusal: the save succeeded, with the numbered slug.",
       example: {
         request: { subject: "Hello, world", markdown: "# Hello\n\nWelcome." },
         response: {
-          post: { id: "p_abc123", status: "draft", slug: "hello-world", slug_auto: true },
+          post: {
+            id: "p_abc123",
+            status: "draft",
+            slug: "hello-world",
+            slug_auto: true,
+            unlisted_token: "9f2c41d0-7ab35e8c-6d1f04b2-a7e9c350",
+            archive_url: "https://newsletter.example.com/archive/hello-world",
+            unlisted_url: "https://newsletter.example.com/email/9f2c41d0-7ab35e8c-6d1f04b2-a7e9c350",
+            published_at: null,
+            archive_live: false
+          },
+          subject_slug_held: null,
           revision_id: "r_1"
         }
       },
@@ -11062,6 +11983,7 @@ function createRouter({
       access: "admin",
       resource: "posts",
       summary: "One post with its current markdown and any active schedule; `scheduled.remade_at` says when a template or identity change last re-made its email.",
+      description: "`subject_slug_held` is the slug the post's subject gives it when another post holds it, so its address didn't follow the subject; null otherwise, and once the post is published, since its address is fixed (SPEC \xA74). It reports a numbered slug, not a refusal.",
       handler: getPost2
     },
     {
@@ -11071,7 +11993,7 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "posts",
       summary: "Update a draft. Send the revision you read as `base_revision` (or If-Match): a save without one is a 428 `base_required` carrying the post as it stands, and one whose base is no longer current is a 409 `stale_revision`.",
-      description: "Only a draft is editable; a scheduled post is soft-locked until its schedule is canceled, and a save to a post that is not a draft is a 409 `post_not_draft` (its message says whether canceling the schedule would unlock it). While the post's slug follows the subject (`slug_auto: true`), every save derives it from the subject again and numbers it if another post holds it, so take the slug from the answer. Sending `slug` sets it by hand and turns `slug_auto` off; `slug_auto: true` has it follow the subject again. Sending both is a 400 naming `slug`.",
+      description: "Only a draft is editable; a scheduled post is soft-locked until its schedule is canceled, and a save to a post that is not a draft is a 409 `post_not_draft` (its message says whether canceling the schedule would unlock it). While the post's slug follows the subject (`slug_auto: true`), every save derives it from the subject again, taking the first free number after the subject's slug (`-2`) when another post holds it, and `subject_slug_held` names the one it couldn't take. Take the slug from the answer. Sending `slug` sets it by hand and turns `slug_auto` off; `slug_auto: true` has it follow the subject again. Sending both is a 400 naming `slug`. A slug set by hand that is malformed is a 400 `slug_invalid`, and one another post holds a 409 `slug_taken`; neither saves anything.",
       example: {
         request: {
           subject: "Hello again, world",
@@ -11098,6 +12020,33 @@ function createRouter({
       summary: "Delete a draft and its revisions (drafts only; any other post is a 409 `post_not_draft`).",
       handler: deletePost2
     },
+    {
+      method: "PUT",
+      path: "/api/posts/:id/settings",
+      access: "admin",
+      accepts: JSON_BODY,
+      resource: "posts",
+      summary: "Set a post's publishing options: where it is listed (`email_only`) and its archive address (`slug`, `slug_auto`) (SPEC \xA74, \xA75).",
+      description: "Any subset of the three. Allowed in any state, a scheduled or sent post's included: none is part of the frozen email, which carries the post's unlisted link, so a change never re-makes a scheduled send or alters a sent one (I3). `email_only: true` mails the post as usual but leaves it out of the archive index and the landing page, and its archive address stops answering, though it stays the post's; its unlisted link opens the page. `false` lists it. Schedule and Send now take the same three fields; a reschedule takes none, since it moves only the time. `slug` sets the archive address by hand and `slug_auto: true` has it follow the subject again, as for a save: a malformed slug is a 400 `slug_invalid` and another post's a 409 `slug_taken`. Once the post's send has started, or while its scheduled email (frozen before unlisted links) links its archive address, its address is fixed: a change to it is a 409 `slug_permanent`, while naming the address it has is fine. Each of the post's sends carries the listing and the address in its view, so they take a new `rev` and the send feed reports them. Answers with the post as it now stands (its `archive_live` says at once whether its archive address shows it), its `subject_slug_held`, and `changed: false` when nothing changed. A body naming none of the three, or a field of the wrong type, is a 400 naming it.",
+      example: {
+        request: { email_only: false, slug: "hello-world" },
+        response: {
+          post: {
+            id: "p_abc123",
+            status: "sent",
+            slug: "hello-world",
+            email_only: false,
+            archive_url: "https://newsletter.example.com/archive/hello-world",
+            unlisted_url: "https://newsletter.example.com/email/9f2c41d0-7ab35e8c-6d1f04b2-a7e9c350",
+            published_at: 17684676e5,
+            archive_live: true
+          },
+          subject_slug_held: null,
+          changed: true
+        }
+      },
+      handler: setSettings
+    },
     {
       method: "GET",
       path: "/api/posts/:id/revisions",
@@ -11122,6 +12071,7 @@ function createRouter({
       accepts: [...FORM_UPLOAD, ...RASTER_IMAGE_TYPES],
       resource: "posts",
       summary: "Upload an image to a draft (multipart form field `file`); a post that is not a draft is a 409 `post_not_draft`.",
+      description: "The post's Markdown references the image by the `filename` the response gives, `![a short description](cover.jpg)`, and the render resolves that name to the stored image.",
       handler: uploadImage
     },
     {
@@ -11147,7 +12097,7 @@ function createRouter({
       access: "admin",
       resource: "posts",
       summary: "Render the post to its email (returns the hosted URL, subject, warnings, and `frozen`).",
-      description: "Once the post is scheduled this is its frozen copy, exactly as it will fire, and once sent the record's; a draft renders live (SPEC \xA75).",
+      description: "Once the post is scheduled this is its frozen copy, exactly as it will fire, and once sent the record's; a draft renders live (SPEC \xA75). A frozen copy's `warnings` are the ones its render gave when it was frozen or last re-made.",
       handler: preview
     },
     {
@@ -11175,11 +12125,12 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "posts",
       summary: "Send a test to one address through the same per-recipient path as a real send (I5).",
-      description: "Once the post is scheduled this sends its frozen copy, exactly as it will fire, and once sent the record's; a draft's test is a live render (SPEC \xA75). The response's `frozen` says which. A test of a scheduled send's frozen copy is recorded as its `tested_at`, which clears the send's `remade` condition. " + notConnected,
+      description: "Once the post is scheduled this sends its frozen copy, exactly as it will fire, and once sent the record's; a draft's test is a live render (SPEC \xA75). The response's `frozen` says which, and its `warnings` are that copy's: a frozen copy's are the ones its render gave when it was frozen or last re-made. A test of a scheduled send's frozen copy is recorded as its `tested_at`, which clears the send's `remade` condition. `sent` is true only when the provider took the test. When it didn't, `not_sent` says why: the provider's own words as `error` (never a credential), a `message` to show or relay as it stands, with the fix where it is known (the same advice as a send's `refused` condition, so a test refused for the account or the address isn't simply tried again), and `may_have_arrived`, true when the provider never answered: then the test may be in the inbox, and the answer is still a 200, never a server error. " + notConnected,
       example: {
         request: { to: "you@example.com" },
         response: {
           sent: true,
+          not_sent: null,
           provider: "ses",
           to: "you@example.com",
           subject: "Hello, world",
@@ -11224,10 +12175,10 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "posts",
       summary: `Freeze the render and schedule the send for a future time (at least ${formatLead(minLeadMs)} out).`,
-      description: "Freezes the current draft, with the template and identity as they stand, onto a send row and soft-locks the post; cancelable until its fire time. A later template or identity change re-makes that frozen email after the publisher confirms it (SPEC \xA76); there is no per-send template to name, and a `template_revision` field is a 400. `fire_at` is epoch milliseconds or an ISO-8601 timestamp with a `Z` or `\xB1hh:mm` offset; a timestamp without one is a 400, since the Worker cannot know which local time was meant. `fire_at` must be at least the minimum lead out, a 400 `fire_at_too_soon` otherwise (for the soonest send, use Send now, `POST /api/posts/:id/send`): " + lead + ". The time is then rounded up to the next whole minute (one already on the minute stays), since the sweep fires sends on the minute; the lead is checked on the time as requested, so rounding only lengthens the window. Answers with the new send's view (as `GET /api/sends/:id` describes it) and a `cursor` to follow it from. Refusals: 409 `active_send_exists` when the post already has its one active send (carried as `send`), 409 `post_not_draft`, 400 `subject_required` for an empty subject, 409 `settings_changed` when a template or identity save kept landing while it froze (try again), and 409 `provider_not_connected` while no email provider is connected (SPEC \xA79).",
+      description: "Freezes the current draft, with the template and identity as they stand, onto a send row and soft-locks the post; cancelable until its fire time. A later template or identity change re-makes that frozen email after the publisher confirms it (SPEC \xA76); there is no per-send template to name, and a `template_revision` field is a 400. `fire_at` is epoch milliseconds or an ISO-8601 timestamp with a `Z` or `\xB1hh:mm` offset; a timestamp without one is a 400, since the Worker cannot know which local time was meant. `fire_at` must be at least the minimum lead out, a 400 `fire_at_too_soon` otherwise (for the soonest send, use Send now, `POST /api/posts/:id/send`): " + lead + ". The time is then rounded up to the next whole minute (one already on the minute stays), since the sweep fires sends on the minute; the lead is checked on the time as requested, so rounding only lengthens the window. `email_only` (optional) sets the post's listing as it is scheduled (SPEC \xA75): `true` mails it as usual but leaves it out of the archive index and the landing page, `false` lists it; absent, the post keeps the listing it has, which is in the archive unless it was set otherwise. `slug` and `slug_auto` (optional) set its archive address as `PUT /api/posts/:id/settings` does, checked before anything is frozen, so a 400 `slug_invalid` or 409 `slug_taken` schedules nothing, and a refused schedule changes neither. None is part of the frozen email. Answers with the new send's view (as `GET /api/sends/:id` describes it), a `cursor` to follow it from, and `warnings`, what the render found wrong with the frozen copy (an image the post never uploaded, say), which preview and test of the copy report too (SPEC \xA75). Refusals: 409 `active_send_exists` when the post already has its one active send (carried as `send`), 409 `post_not_draft`, 400 `subject_required` for an empty subject, 409 `settings_changed` when a template or identity save kept landing while it froze (try again), and 409 `provider_not_connected` while no email provider is connected (SPEC \xA79).",
       example: {
         request: { fire_at: "2026-01-16T09:00:00Z" },
-        response: { send: scheduledExample, cursor: "57.1768467610000" }
+        response: { send: scheduledExample, cursor: "57.1768467610000", warnings: [] }
       },
       handler: schedule
     },
@@ -11238,9 +12189,10 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "posts",
       summary: "Send now: freeze and schedule one minimum lead out, on the minute, cancelable until then. Idempotent per post.",
-      description: "The same freeze as scheduling, with the template and identity as they stand, and `fire_at` set to now plus the minimum lead, rounded up to the next whole minute as every fire time is: " + lead + ". For nearly all of that window the send is inside the minimum lead, so a template or identity save that would re-make it is refused until it has fired. A second call for a post already in its window answers with that send and `idempotent: true`; the other refusals are as for scheduling.",
+      description: "The same freeze as scheduling, with the template and identity as they stand, and `fire_at` set to now plus the minimum lead, rounded up to the next whole minute as every fire time is: " + lead + ". For nearly all of that window the send is inside the minimum lead, so a template or identity save that would re-make it is refused until it has fired. An optional JSON body may carry `email_only`, `slug`, and `slug_auto`, the post's settings, as for scheduling. A second call for a post already in its window answers with that send and `idempotent: true`, and changes nothing, its listing included; one that names settings the post doesn't have is a 409 `active_send_exists` carrying the send, so a caller that asked for email only never reads success for a post going out listed (change them with `PUT /api/posts/:id/settings`). Its answer carries `warnings` as scheduling's does, a repeat's included. The other refusals are as for scheduling.",
       example: {
-        response: { send: scheduledExample, cursor: "57.1768467610000" }
+        request: { email_only: true },
+        response: { send: scheduledExample, cursor: "57.1768467610000", warnings: [] }
       },
       handler: sendNow
     },
@@ -11250,7 +12202,7 @@ function createRouter({
       access: "admin",
       resource: "sends",
       summary: "List sends with delivery progress. Filter, sort, and paginate via query params; returns a `page` envelope. Each row is the send's view, the same shape `GET /api/sends/:id`, the feed, and every action answer with (see `GET /api/sends/:id`), read at the same moment, so a list row and the watch never read a send differently. A row's `rev` rises with every change a reader could see (a cancel, a move, a re-make, dispatch progress, a receipt), ordered across all sends. The response's `cursor` marks where this read stood among those changes: `<seq>.<at>`, the change sequence at the read and the server's time of it (epoch milliseconds), both decimal; pass it to `GET /api/sends/feed` as `since`. `audience.count` is a snapshot of the audience while a send is scheduled; once it fires (`audience.fixed`), it is the audience fixed at fire, which never grows.",
-      description: "`provider.halt` describes a `sending` send whose provider refused its last batch as a whole (SPEC \xA712), and is null otherwise: its `reason`, `cause`, the provider's own words as `error`, and `since`. The send retries on its own, spaced out the longer the halt lasts: `retries` counts the halted attempts in a row and `retry_at` is when the next is due, up to an hour apart, and both reset the moment a batch is answered. `unavailable` is an outage or a rate limit, retried " + retrySchedule(HALT_BACKOFF_MS.unavailable) + ", and worth raising only once the send carries the `stuck` condition. `account` is the provider refusing the account itself, retried " + retrySchedule(HALT_BACKOFF_MS.account) + "; `cause` names what (`credentials`, `configuration`, `sender`, `quota`, `suspended`, or `not_connected`, a deployment with no provider connected). Either way no recipient has been consumed. The fix for `account` is outside this API (the provider's dashboard, or the deployment's secrets, which the API never exposes, SPEC \xA79), and once it lands the send resumes by itself at its next retry, so it is never rescheduled or sent again. There is no API action to retry sooner. " + conditionsText + " An unknown `status`, `failures`, `sort`, or `dir`, or a `limit` or `offset` that is not a whole number, is a 400 naming the field.",
+      description: "`provider.halt` describes a `sending` send whose provider refused its last batch as a whole (SPEC \xA712), and is null otherwise: its `reason`, `cause`, the provider's own words as `error`, and `since`. A halt is the account's or the provider's, so a send that fires or resumes while another send waits one out joins it without asking the provider, unless the halt is the provider refusing that one send (`content` or `invalid_request`, below): it carries the same halt and retries with it, and fixes its audience when it first hands off (`audience.fixed` stays false until then). The send retries on its own, spaced out the longer the halt lasts: `retries` counts the halted attempts in a row and `retry_at` is when the next is due, up to an hour apart, and both reset the moment the provider takes anyone, except that an answer that takes some and refuses the rest for the account (a quota freeing up a few at a time) continues an `account` halt, its `since` and its spacing. `unavailable` is an outage or a rate limit, retried " + retrySchedule(HALT_BACKOFF_MS.unavailable) + ", shown as the `provider_unavailable` condition and the `backing-off` phase while it lasts; it clears on its own, so it is never also `stuck` until its retry is long overdue. `account` is the provider refusing the account itself, retried " + retrySchedule(HALT_BACKOFF_MS.account) + "; `cause` names what (`credentials`, `opt_in`, `configuration`, `sending_pool`, `unsupported`, `sender`, `mail_from`, `sandbox`, `quota`, `suspended`, `paused`, `set_paused`, or `not_connected`, a deployment with no provider connected; or this send's own `content`, an email the provider refuses, or `invalid_request`, a batch it refused as invalid without naming a recipient), and the condition's `advice` says the fix and who makes it. An `unavailable` halt's `cause` is `rate_limit` or `outage`. Either way no recipient has been consumed. The fix for `account` is outside this API (the provider's dashboard, or the deployment's secrets, which the API never exposes, SPEC \xA79), and once it lands the send resumes by itself at its next retry, so it is never rescheduled or sent again. There is no API action to retry sooner. " + conditionsText + " An unknown `status`, `failures`, `sort`, or `dir`, or a `limit` or `offset` that is not a whole number, is a 400 naming the field.",
       query: [
         {
           name: "status",
@@ -11284,7 +12236,7 @@ function createRouter({
       access: "admin",
       resource: "sends",
       summary: "What changed among sends since a cursor, each send with its phase, counters, conditions, and actions, every open condition across the sends, and when to read again: what a client follows to keep up with sends, whichever client changed them, without polling each one.",
-      description: `With \`since\` (the \`cursor\` from \`GET /api/sends\`, \`GET /api/sends/:id\`, or this route's last read), \`sends\` is every send that changed after that read, whatever its state: a cancel, a move, a re-make, a new schedule, dispatch progress, a receipt, a completion. It also holds each send the clock changed with no write since then: one whose fire time passed (\`due\`), one past the ${MISSED_THRESHOLD_MS / 6e4}-minute missed tolerance (the \`missed\` condition), and one in flight past the ${STUCK_THRESHOLD_MS / 6e4}-minute stuck threshold (\`stuck\`). A send turns wedged (\`wedged\`) by a write, when the run that left recipients with an unknown fate hands it back, so it is reported like any other change. \`removed\` is every send removed after the cursor (a canceled send deleted with its post), each \`{id, rev}\`, so a client drops it rather than keeping a row for a send that is gone. Without \`since\`, \`sends\` is every send that can change on its own: due, \`sending\`, or settling (\`sent\` within the last ${SETTLE_FOLLOW_MS / 6e4} minutes with a recipient still awaiting a receipt), and \`removed\` is empty. Either way each send is its view, the shape \`GET /api/sends/:id\` describes, read off the send's counters, never its delivery rows, so a send reads the same here as on its page; soonest fire first. \`cursor\` is where this read stood, to pass as \`since\` next time: \`<seq>.<at>\`, the change sequence at the read and the server's time of it (\`now\`), both decimal. The format is part of this contract, so a client holding cursors from several reads (a list, and one send's page) may compare them and follow everything from one read: the cursor with the smaller of each number answers for both. A read reports at most \`limit\` changes after the cursor, in the order they were made, and never splits the changes one write made; the sends the clock changed are always all reported. When more are waiting, \`more\` is true, \`cursor\` stands where the read stopped, and \`read_again_at\` is \`now\`: read again at once from it. A cursor ahead of this database (a sequence above the current one, or a read time more than a minute after \`now\`, as after a reset or a restore of the database) is a 409 \`cursor_ahead\` naming \`since\`: nothing after it would ever be reported, so read the sends again (\`GET /api/sends\` or \`GET /api/sends/:id\`) and follow from that read's cursor. \`read_again_at\` is when to read again, by the server's clock (\`now\`), from each unfinished send's \`next_change_at\`, the earliest it can change with no one acting: about 3 seconds while any send can move now (due, short of the missed tolerance, or sending with a run in hand or work queued for the next tick); while sends are only settling, 3 seconds, then 15, then 60, by how long ago the youngest finished dispatch; otherwise about once a minute (one sweep tick); and never later than just past the next change the clock or the sweep will make (a fire time, a halted send's next retry, the stuck threshold). A send waiting on a person (the provider refusing the account, a wedged send awaiting Resolve, a missed fire time) does not quicken it. A client that reads again then is never more than a few seconds behind a send that is moving, behind a settling send's receipts by at most that pace, and behind any other change (the other client's cancel or move, a Resolve, a late receipt) by about a minute. \`read_again_at\` is advisory: reading sooner, such as right after acting on a send, is always fine, and reading late or skipping a read loses nothing, since the next read from the last cursor reports every send that changed in between. \`GET /api/sends\` and \`GET /api/sends/:id\` carry no pace of their own: a client following from one of them reads this route at once, then keeps to its \`read_again_at\`. \`conditions\` repeats every open condition across the sends that can have one (scheduled, sending, and sent within the bounce-spike window), each with its \`send_id\` and \`subject\`, whether or not the send changed, so one read shows every open problem; most severe first. ${conditionsText} Reading it changes nothing.`,
+      description: `With \`since\` (the \`cursor\` from \`GET /api/sends\`, \`GET /api/sends/:id\`, or this route's last read), \`sends\` is every send that changed after that read, whatever its state: a cancel, a move, a re-make, a new schedule, dispatch progress, a receipt, a completion. It also holds each send the clock changed with no write since then: one whose fire time passed (\`due\`), one past the ${MISSED_THRESHOLD_MS / 6e4}-minute missed tolerance (the \`missed\` condition), and one idle past the ${STUCK_THRESHOLD_MS / 6e4}-minute stuck threshold (\`stuck\`). A send turns wedged (\`wedged\`) by a write, when the run that left recipients with an unknown fate hands it back, so it is reported like any other change. \`removed\` is every send removed after the cursor (a canceled send deleted with its post), each \`{id, rev}\`, so a client drops it rather than keeping a row for a send that is gone. Without \`since\`, \`sends\` is every send that can change on its own: due, \`sending\`, or settling (\`sent\` within the last ${SETTLE_FOLLOW_MS / 6e4} minutes with a recipient still awaiting a receipt), and \`removed\` is empty. Either way each send is its view, the shape \`GET /api/sends/:id\` describes, read off the send's counters, never its delivery rows, so a send reads the same here as on its page; soonest fire first. \`cursor\` is where this read stood, to pass as \`since\` next time: \`<seq>.<at>\`, the change sequence at the read and the server's time of it (\`now\`), both decimal. The format is part of this contract, so a client holding cursors from several reads (a list, and one send's page) may compare them and follow everything from one read: the cursor with the smaller of each number answers for both. A read reports at most \`limit\` changes after the cursor, in the order they were made, and never splits the changes one write made; the sends the clock changed are always all reported. When more are waiting, \`more\` is true, \`cursor\` stands where the read stopped, and \`read_again_at\` is \`now\`: read again at once from it. A cursor ahead of this database (a sequence above the current one, or a read time more than a minute after \`now\`, as after a reset or a restore of the database) is a 409 \`cursor_ahead\` naming \`since\`: nothing after it would ever be reported, so read the sends again (\`GET /api/sends\` or \`GET /api/sends/:id\`) and follow from that read's cursor. \`read_again_at\` is when to read again, by the server's clock (\`now\`), from each unfinished send's \`next_change_at\`, the earliest it can change with no one acting: about 3 seconds while any send can move now (due, short of the missed tolerance, or sending with a run in hand or work queued for the next tick); while sends are only settling, 3 seconds, then 15, then 60, by how long ago the youngest finished dispatch; otherwise about once a minute (one sweep tick); and never later than just past the next change the clock or the sweep will make (a fire time, a halted send's next retry). A send waiting on a person (the provider refusing the account, a wedged send awaiting Resolve, a missed fire time) does not quicken it. A client that reads again then is never more than a few seconds behind a send that is moving, behind a settling send's receipts by at most that pace, and behind any other change (the other client's cancel or move, a Resolve, a late receipt) by about a minute. \`read_again_at\` is advisory: reading sooner, such as right after acting on a send, is always fine, and reading late or skipping a read loses nothing, since the next read from the last cursor reports every send that changed in between. \`GET /api/sends\` and \`GET /api/sends/:id\` carry no pace of their own: a client following from one of them reads this route at once, then keeps to its \`read_again_at\`. \`conditions\` repeats every open condition across the sends that can have one (scheduled, sending, and sent within the bounce-spike window), each with its \`send_id\` and \`subject\`, whether or not the send changed, so one read shows every open problem; most severe first. ${conditionsText} Reading it changes nothing.`,
       query: [
         {
           name: "since",
@@ -11344,7 +12296,7 @@ function createRouter({
       access: "admin",
       resource: "sends",
       summary: "One send: its view, the delivery-outcome breakdown of its record, and the `cursor` marking where this read stood among the changes to sends, to follow it from with `GET /api/sends/feed` (it carries no pace, so read the feed at once from it).",
-      description: "`send` is the send's view, the one shape every send route carries (the list, the feed, every action's answer and refusal), so a client keeps one copy current from any of them and tells two apart by `rev`, the higher the newer. It holds the stored facts: `status` (`scheduled`, `sending`, `sent`, `canceled`), the times, `remade_at` (a template or identity change re-made it while scheduled) and `tested_at`, and `audience` (`count`, an estimate until the send fires and the audience at fire once `fixed`, from `fixed_at`). Beside them, what the server derives as of `as_of`, the server's clock at the read: `counts` (every recipient in one bucket), `dispatch` (hand-off progress; `rate_per_min` is what a sweep tick carries, one tick a minute, and `eta_ms` counts the ticks the rest needs, the wait between them included, given only while it is handing off and once a tick has finished, never while paused), `delivery` (receipts over accepted), `provider` (its `name`, and `halt` while the provider refuses its batches), `phase` (`scheduled`, `due`, `progressing`, `retrying`, `backing-off`, `needs-attention`, `settling`, `complete`, `canceled`), `conditions`, `actions`, and `next_change_at` (see `GET /api/sends/feed`). `links` names the send's other resources: the frozen email (`email_html`, `email_text`), the recipient rows and their CSV, the post, and `archive`, the published page, absolute, once the send is sent. " + conditionsText + " `outcomes` counts the record's recipients by outcome from its rows, summing to the audience at fire. The answer carries `ETag`: the send's `rev` and a tag of what the clock derives from it, so a request with `If-None-Match` answers 304 while nothing about the send has changed, written or derived.",
+      description: "`send` is the send's view, the one shape every send route carries (the list, the feed, every action's answer and refusal), so a client keeps one copy current from any of them and tells two apart by `rev`, the higher the newer. It holds the stored facts: `status` (`scheduled`, `sending`, `sent`, `canceled`), the times, `remade_at` (a template or identity change re-made it while scheduled) and `tested_at`, and `audience` (`count`, an estimate until the send fires and the audience at fire once `fixed`, from `fixed_at`). Beside them, what the server derives as of `as_of`, the server's clock at the read: `counts` (every recipient in one bucket), `dispatch` (hand-off progress; `rate_per_min` is what a sweep tick carries, one tick a minute, and `eta_ms` counts the ticks the rest needs, the wait between them included, given only while it is handing off and once a tick has finished, never while paused or in flight too long), `delivery` (receipts over accepted), `provider` (its `name`, and `halt` while the provider refuses its batches), `phase` (`scheduled`, `due`, `progressing`, `retrying`, `backing-off`, `needs-attention`, `settling`, `complete`, `canceled`), `conditions`, `actions`, and `next_change_at` (see `GET /api/sends/feed`). `links` names the send's other resources: the frozen email (`email_html`, `email_text`), the recipient rows and their CSV, the post, and `archive`, the published page, absolute, once the send is sent. " + conditionsText + " `outcomes` counts the record's recipients by outcome from its rows, summing to the audience at fire. The answer carries `ETag`: the send's `rev` and a tag of what the clock derives from it, so a request with `If-None-Match` answers 304 while nothing about the send has changed, written or derived.",
       example: {
         response: {
           send: sendExample(),
@@ -11452,7 +12404,7 @@ function createRouter({
       accepts: JSON_BODY,
       resource: "sends",
       summary: "Move a scheduled send's fire time without re-freezing the render (I3, I6).",
-      description: "Updates only `fire_at` on a send still in its review window: the frozen render is untouched (the audience is resolved when the send fires) and the review window is preserved; a re-made send keeps its `remade_at`. Distinct from cancel \u2192 edit \u2192 schedule again, which is for content changes. The same `fire_at` form as scheduling (epoch milliseconds or an ISO-8601 timestamp with a `Z` or `\xB1hh:mm` offset), and the same minimum lead, a 400 `fire_at_too_soon` otherwise: " + lead + ". As when scheduling, the new time is rounded up to the next whole minute, after the lead is checked on the time as requested. A move to the time the send already has (after that rounding) answers 200 with `changed: false` before the lead is checked, so a retried move is safe. Once the fire time has passed it is a 409 `window_closed`, and a canceled send is a 409 `send_canceled` (schedule the post again instead). " + actionText,
+      description: "Updates only `fire_at` on a send still in its review window: the frozen render is untouched (the audience is resolved when the send fires) and the review window is preserved; a re-made send keeps its `remade_at`. Distinct from cancel \u2192 edit \u2192 schedule again, which is for content changes. The same `fire_at` form as scheduling (epoch milliseconds or an ISO-8601 timestamp with a `Z` or `\xB1hh:mm` offset), and the same minimum lead, a 400 `fire_at_too_soon` otherwise: " + lead + ". As when scheduling, the new time is rounded up to the next whole minute, after the lead is checked on the time as requested. A move to the time the send already has (after that rounding) answers 200 with `changed: false` before the lead is checked, so a retried move is safe. Once the fire time has passed it is a 409 `window_closed`, and a canceled send is a 409 `send_canceled` (schedule the post again instead). The post's settings are not a reschedule's: `email_only`, `slug`, or `slug_auto` is a 400 naming the field, which moves nothing; change them with `PUT /api/posts/:id/settings`. " + actionText,
       example: {
         request: { fire_at: "2026-01-16T09:00:00Z" },
         response: { send: scheduledExample, cursor: "58.1768467620000", changed: true }
@@ -11842,7 +12794,19 @@ function createRouter({
       handler: unsubscribe
     },
     // --- delivery webhooks (public; provider-signature-verified, not requireAuth) ---
-    // --- archive / view-in-browser (public; serves the frozen record, I3) ---
+    // --- unlisted links (public; the "view in browser" every email carries, SPEC §5) ---
+    // On the app's own origin and independent of ARCHIVE_BASE_PATH, so moving the archive
+    // breaks no email already sent.
+    {
+      method: "GET",
+      path: `${UNLISTED_PATH}/:token`,
+      access: "public",
+      resource: "archive",
+      summary: "A post's unlisted link, the view-in-browser link every test and send carries (SPEC \xA75).",
+      description: "Before the post's send starts, the same `Nothing here yet` page (404) as any unknown token. Once it has: while the post is listed, a temporary redirect (302, `Cache-Control: no-store`, `X-Robots-Tag: noindex`) to its own archive address, since the listing can change, and never to anything the request names; while it is email only, the post's page itself, with `X-Robots-Tag: noindex` and `Cache-Control: no-cache`. Public, but never listed or linked from any page. A GET only reads, so a mail client's link scanner following it changes nothing.",
+      handler: unlistedPage
+    },
+    // --- archive (public; serves the frozen record, I3) ---
     // Registered at ARCHIVE_BASE_PATH (default /archive) so the index, the post
     // 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).
@@ -11862,7 +12826,8 @@ function createRouter({
       path: `${archiveBasePath}/:slug`,
       access: "public",
       resource: "archive",
-      summary: "A published post's archive page / view-in-browser (I3), from the moment its send starts.",
+      summary: "A published post's archive page (I3), from the moment a listed post's send starts, while it stays listed.",
+      description: "An email-only post's address answers the `Nothing here yet` page (404) but stays the post's, so listing it again brings it back. The exception is a post whose email carries this address as its view-in-browser link (one sent before unlisted links): its address answers whatever its listing, with `X-Robots-Tag: noindex` while it is email only. The page is sent with `Cache-Control: no-cache`, so a listing change takes effect at once.",
       handler: archivePage
     },
     // --- media bytes (public; readers + archive load these unauthenticated) ---
@@ -11888,7 +12853,12 @@ var SHIPPED_MIGRATIONS = [
   "0003_post_slug_auto.sql",
   "0004_keyed_pending_to_resolve.sql",
   "0005_imports.sql",
-  "0006_deliveries_fewer_indexes.sql"
+  "0006_deliveries_fewer_indexes.sql",
+  "0007_sends_progress_at.sql",
+  "0008_notifications_sandbox.sql",
+  "0009_post_email_only.sql",
+  "0010_unlisted_links.sql",
+  "0011_sends_render_warnings.sql"
 ];
 async function missingMigrations(db) {
   let applied;
@@ -12027,13 +12997,14 @@ var MAX_PER_TICK = 10;
 function stillHolds(n, now) {
   switch (n.kind) {
     case "import":
+    case "sandbox":
       return true;
     case "finished":
       return true;
     case "refused":
       return n.send_status === "sending" && n.halt_reason === "account" && n.halted_at === n.episode;
     case "stuck":
-      return n.send_status === "sending";
+      return idleSince({ ...n, status: n.send_status }) === n.episode;
     case "wedged":
       return isWedged({ ...n, status: n.send_status });
     case "missed":
@@ -12069,11 +13040,11 @@ async function notifyPublisher(env, budget) {
       await recordNotificationOutcome(db, n, { status: "cleared" }, Date.now());
       continue;
     }
-    const about = n.kind === "import" ? { importId: n.import_id } : { sendId: n.send_id };
-    const key = `${n.send_id ?? n.import_id}-${n.kind}-${n.episode}`;
+    const about = n.kind === "import" ? { importId: n.import_id } : n.kind === "sandbox" ? {} : { sendId: n.send_id };
+    const key = `${n.send_id ?? n.import_id ?? "account"}-${n.kind}-${n.episode}`;
     budget.request();
     try {
-      const email2 = n.kind === "import" ? composeImportNotification(n, config) : composeNotification(n, config);
+      const email2 = n.kind === "import" ? composeImportNotification(n, config) : n.kind === "sandbox" ? composeSandboxNotification(config) : composeNotification(n, config);
       await notifier.send(to, email2, key);
       await recordNotificationOutcome(db, n, { status: "sent" }, Date.now());
       log.info("notify.sent", { ...about, kind: n.kind, channel: notifier.channel });
@@ -12138,13 +13109,13 @@ var SendWindow = class {
 // src/send/loop.ts
 var MAX_CHUNK = 500;
 var GROUP_RECIPIENTS = 10;
-var OPEN_COST2 = 5;
+var OPEN_COST2 = 6;
 var GROUP_COST = 8;
 var GROUP_TYPICAL_COST = 5;
 var CLOSE_COST = 4;
 var MIN_RUN_COST = OPEN_COST2 + GROUP_COST + 1 + CLOSE_COST;
 function worseHalt(current2, next) {
-  return !current2 || current2.reason === "unavailable" && next.reason === "account" ? next : current2;
+  return !current2 || haltRank(next) > haltRank(current2) ? next : current2;
 }
 function chunk2(items, size) {
   const out = [];
@@ -12199,6 +13170,20 @@ async function runSend(env, sendId, budget = new Budget(getConfig(env).subreques
     renewAt = Date.now() + LEASE_TTL_MS / 2;
     return renewLease(db, sendId, lease, Date.now() + LEASE_TTL_MS);
   };
+  const standing = await accountHalt(db, sendId, Date.now() + HALT_RETRY_SLACK_MS);
+  if (standing) {
+    await joinHalt(db, sendId, lease, standing);
+    log.warn("send.halted", {
+      ...tags,
+      reason: standing.reason,
+      cause: standing.cause,
+      error: standing.error,
+      retryAt: new Date(standing.retryAt).toISOString(),
+      heldBy: standing.sendId
+    });
+    await releaseLease(db, sendId, lease);
+    return { ...empty, leased: true, halt: standing.reason };
+  }
   if (send.audience_resolved_at === null) {
     await resolveAudience(db, sendId, now);
   }
@@ -12214,7 +13199,7 @@ async function runSend(env, sendId, budget = new Budget(getConfig(env).subreques
     const held = [];
     let halt = null;
     let requeued = 0;
-    let answered = false;
+    let progressed = false;
     let complete = true;
     let latencyMs = 0;
     let heldCount = 0;
@@ -12282,7 +13267,7 @@ async function runSend(env, sendId, budget = new Budget(getConfig(env).subreques
         batchHalt = answer.halt;
       } else {
         if (answer.results.some((r) => r.accepted || r.held !== true)) {
-          answered = true;
+          progressed = true;
         }
         if (answer.halt) {
           halt = worseHalt(halt, answer.halt);
@@ -12320,7 +13305,11 @@ async function runSend(env, sendId, budget = new Budget(getConfig(env).subreques
         halt = worseHalt(halt, batchHalt);
       }
     }
-    await settleDeliveries(db, sendId, lease, "dispatched", outcomes, Date.now(), answered);
+    const cleared = progressed && halt?.reason !== "account";
+    await settleDeliveries(db, sendId, lease, "dispatched", outcomes, Date.now(), {
+      progressed,
+      clears: cleared
+    });
     const heldAt = Date.now();
     await holdBatch(
       db,
@@ -12348,7 +13337,7 @@ async function runSend(env, sendId, budget = new Budget(getConfig(env).subreques
       unknown,
       latencyMs
     });
-    if (answered && halted) {
+    if (cleared && halted) {
       log.info("send.resumed", {
         ...tags,
         reason: halted.reason,
@@ -12478,6 +13467,20 @@ async function runTick(env, now, tick) {
   const budget = new Budget(whole.limit - held, whole.queryLimit - held);
   const db = metered(env.DB, budget);
   const window = new SendWindow(getProvider(config, env).maxRequestRate);
+  const resumable = await resumableSends(db, now, now + HALT_RETRY_SLACK_MS);
+  const resume = async (s) => {
+    if (handled.has(s.id) || !budget.affords(MIN_RUN_COST)) {
+      return;
+    }
+    handled.add(s.id);
+    tick.resumable += 1;
+    await safeRun(env, s.id, budget, window);
+  };
+  for (const s of resumable) {
+    if (s.halt_reason !== null) {
+      await resume(s);
+    }
+  }
   for (const s of await dueSends(db, now)) {
     const lag = now - s.fire_at;
     if (lag > MISSED_THRESHOLD_MS) {
@@ -12488,17 +13491,16 @@ async function runTick(env, now, tick) {
     tick.due += 1;
     await safeRun(env, s.id, budget, window);
   }
-  const resumable = budget.affords(1 + MIN_RUN_COST) ? await resumableSends(db, now, now + HALT_RETRY_SLACK_MS) : [];
   for (const s of resumable) {
-    if (handled.has(s.id)) {
-      continue;
-    }
-    handled.add(s.id);
-    tick.resumable += 1;
-    await safeRun(env, s.id, budget, window);
+    await resume(s);
   }
   for (const s of await stuckSends(env.DB, now - STUCK_THRESHOLD_MS)) {
-    log.error("send.stuck", { sendId: s.id, postId: s.post_id, startedAt: s.started_at });
+    log.error("send.stuck", {
+      sendId: s.id,
+      postId: s.post_id,
+      startedAt: s.started_at,
+      idleSince: idleSince(s)
+    });
     tick.stuck += 1;
   }
   for (const s of await wedgedSends(env.DB)) {