@pithy-sh/support 0.1.1 → 0.1.3

package/dist/reply/snippets.js

@@ -0,0 +1,135 @@
+import { SupportInvalidCategoryError } from "../error/errors.js";
+import { z } from "zod";
+//#region src/reply/snippets.ts
+/**
+* Canned replies — starting points a human picks in the dashboard, edits, and sends.
+*
+* ## What these are, and what they are not
+*
+* A snippet is **body text**, not an email template. The rendering shell — the adopter's theme, the
+* HTML and plain-text pair, the threading headers — is the single `supportReply` template in
+* `@pithy-sh/email`. Adding a second email template per canned reply would put the adopter's
+* wording in a precompiled Handlebars file that only a release can change, which is exactly backwards
+* for text somebody wants to reword on a Tuesday.
+*
+* So the Worker serves a catalog and **never renders it**. The dashboard shows the list, the operator
+* picks one, edits it, and posts the finished body to the reply route — which is why the placeholder
+* tokens below are substituted client-side and this package owns no template engine. A support reply
+* is a letter a person sent; the machine's only job is to hand them a better blank page.
+*
+* ## Federated, like the taxonomy
+*
+* Pithy ships a small set keyed to the default categories, and an adopter adds their own with
+* {@link defineSupportReplies} — the same shape `defineSupportCategories` uses, for the same reason.
+* A snippet tagged with a category is offered first on a thread the classifier put in that category,
+* which is the one place the classification does work for a human rather than for a filter.
+*
+* The shipped wording is deliberately plain and slightly incomplete: every one of them has a blank
+* an operator has to fill. A canned reply that could be sent without reading it is how a support
+* inbox starts insulting people.
+*/
+/** The shape a snippet key must take: lowercase `snake_case`, so it is a stable id in a dashboard. */
+const SNIPPET_KEY = /^[a-z][a-z0-9]*(_[a-z0-9]+)*$/;
+/** How long a snippet body may be. Long enough for a real answer; bounded because it ships in a manifest. */
+const MAX_BODY = 2e3;
+/**
+* The tokens a dashboard substitutes before sending. Documented here because they are a contract
+* between this catalog and whatever renders it, and deliberately few: a placeholder language is a
+* template engine, and a template engine over untrusted context is a rendering vulnerability.
+*/
+const SNIPPET_TOKENS = {
+	/** The sender's display name, or their address when the app knows no name. */
+	name: "{{name}}",
+	/** The thread's subject. */
+	subject: "{{subject}}"
+};
+/** One canned reply. */
+const SupportReplySnippet = z.object({
+	label: z.string().min(1).max(80).describe("What the dashboard shows in the picker, e.g. `Refund issued`. A verb phrase, not a category name."),
+	category: z.string().optional().describe("The category this snippet is offered first for. Optional — a snippet with no category is always offered, which is right for the general-purpose ones."),
+	body: z.string().min(1).max(MAX_BODY).describe("The starting text, with `{{name}}` and `{{subject}}` substituted by the dashboard before sending. Written to be edited: every shipped one leaves a blank a human has to fill.")
+}).describe("One canned reply — a starting point a human picks, edits, and sends.");
+/**
+* The set Pithy ships, keyed to the default categories.
+*
+* Six, not sixteen. A picker long enough to need scrolling is one nobody reads, and the ones below
+* are the replies a solo developer actually writes over and over.
+*/
+const DEFAULT_SUPPORT_REPLIES = {
+	refund_issued: {
+		label: "Refund issued",
+		category: "billing",
+		body: "Hi {{name}},\n\nI've refunded this — you should see it back on your original payment method within ___ working days.\n\nSorry for the trouble.\n"
+	},
+	billing_explained: {
+		label: "Explain a charge",
+		category: "billing",
+		body: "Hi {{name}},\n\nThat charge is ___. It covers ___.\n\nIf that isn't what you expected, tell me and I'll sort it out.\n"
+	},
+	sign_in_help: {
+		label: "Sign-in help",
+		category: "account_access",
+		body: "Hi {{name}},\n\nI've had a look — ___.\n\nTry signing in again and let me know if it still doesn't work. If the email isn't arriving, check your spam folder, and tell me which address you're using so I can confirm it matches the account.\n"
+	},
+	bug_acknowledged: {
+		label: "Bug acknowledged",
+		category: "bug_report",
+		body: "Hi {{name}},\n\nThanks for reporting this — I've reproduced it and it's a real bug. ___.\n\nI'll follow up here once it's fixed.\n"
+	},
+	feature_noted: {
+		label: "Feature request noted",
+		category: "feature_request",
+		body: "Hi {{name}},\n\nThanks — that's a good idea and I've written it down. I can't promise a date, but ___.\n\nIf you can tell me a bit about how you'd use it, that genuinely helps me prioritize.\n"
+	},
+	need_more_detail: {
+		label: "Ask for more detail",
+		body: "Hi {{name}},\n\nHappy to help with this. Could you tell me ___?\n\nA screenshot or the exact wording of any error would speed this up a lot.\n"
+	}
+};
+/**
+* Declare an adopter's own canned replies, validated at author time.
+*
+* The same shape and the same reasoning as `defineSupportCategories`: a malformed key is a picker
+* entry that silently never matches, and it should fail where the constant is written.
+*/
+function defineSupportReplies(snippets) {
+	for (const [key, snippet] of Object.entries(snippets)) {
+		if (!SNIPPET_KEY.test(key)) throw new SupportInvalidCategoryError({
+			message: `Invalid support reply key: ${key}`,
+			action: "Use a lowercase snake_case key, e.g. `refund_issued`.",
+			detail: `key ${JSON.stringify(key)} does not match ${SNIPPET_KEY}`
+		});
+		const parsed = SupportReplySnippet.safeParse(snippet);
+		if (!parsed.success) throw new SupportInvalidCategoryError({
+			message: `Invalid support reply "${key}".`,
+			action: "Give it a label and a body, and keep the body under 2000 characters.",
+			detail: parsed.error.message
+		});
+	}
+	return snippets;
+}
+/** The effective catalog: the shipped set, plus the adopter's, theirs winning on a key collision. */
+function resolveReplies(extra = {}) {
+	return {
+		...DEFAULT_SUPPORT_REPLIES,
+		...defineSupportReplies(extra)
+	};
+}
+/**
+* The catalog as a dashboard consumes it: the snippets for this thread's category first, then the
+* uncategorized general-purpose ones, then everything else.
+*
+* Ordering rather than filtering, deliberately. A classifier that put a refund request in
+* `bug_report` would otherwise hide the refund snippets from the one person who can tell it was
+* wrong — the model orders the list, it never restricts it.
+*/
+function repliesForCategory(snippets, category) {
+	const entries = Object.entries(snippets).map(([key, snippet]) => ({
+		key,
+		...snippet
+	}));
+	const rank = (snippet) => snippet.category === category ? 0 : snippet.category === void 0 ? 1 : 2;
+	return entries.sort((a, b) => rank(a) - rank(b) || a.key.localeCompare(b.key));
+}
+//#endregion
+export { DEFAULT_SUPPORT_REPLIES, SNIPPET_TOKENS, SupportReplySnippet, defineSupportReplies, repliesForCategory, resolveReplies };

package/dist/secret/registry.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The secrets support reads — exactly one, and it is not support's own shape.
+ *
+ * Attachment bytes are written through the R2 binding and served as short-lived signed URLs, and
+ * signing needs an S3 key pair. Rather than declare another credential shape, support declares the
+ * *same* one `@pithy-sh/storage` owns, under its own name, through storage's factory. That is what
+ * lets support point the `ObjectStore` seam at `SUPPORT_BUCKET` while inheriting none of storage's
+ * tables, routes, or key policy — the same arrangement `@pithy-sh/media` already has.
+ *
+ * One factory rather than two hand-written declarations is also what keeps the name safe as a join
+ * key: `aggregateSecretRegistries` allows a name declared twice only when every axis agrees, and two
+ * hand-written copies drift where one factory cannot.
+ */
+/** The name support's R2 credential bundle is stored and resolved under, per environment. */
+export declare const SUPPORT_R2_SECRET = "support-r2-credentials";
+/** The support capability's secret-registry slice — aggregated into the shared accessor at startup. */
+export declare const supportSecretsRegistry: Record<"support-r2-credentials", import("@pithy-sh/storage/src/secret/registry").R2CredentialsEntry>;
+//# sourceMappingURL=registry.d.ts.map

package/dist/secret/registry.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/secret/registry.ts"],"names":[],"mappings":"AAKA;;;;;;;;;;;;GAYG;AAEH,6FAA6F;AAC7F,eAAO,MAAM,iBAAiB,2BAA2B,CAAC;AAE1D,uGAAuG;AACvG,eAAO,MAAM,sBAAsB,sGAA2C,CAAC"}

package/dist/secret/registry.js

@@ -0,0 +1,21 @@
+import { r2CredentialsRegistry } from "@pithy-sh/storage/src/secret/registry";
+//#region src/secret/registry.ts
+/**
+* The secrets support reads — exactly one, and it is not support's own shape.
+*
+* Attachment bytes are written through the R2 binding and served as short-lived signed URLs, and
+* signing needs an S3 key pair. Rather than declare another credential shape, support declares the
+* *same* one `@pithy-sh/storage` owns, under its own name, through storage's factory. That is what
+* lets support point the `ObjectStore` seam at `SUPPORT_BUCKET` while inheriting none of storage's
+* tables, routes, or key policy — the same arrangement `@pithy-sh/media` already has.
+*
+* One factory rather than two hand-written declarations is also what keeps the name safe as a join
+* key: `aggregateSecretRegistries` allows a name declared twice only when every axis agrees, and two
+* hand-written copies drift where one factory cannot.
+*/
+/** The name support's R2 credential bundle is stored and resolved under, per environment. */
+const SUPPORT_R2_SECRET = "support-r2-credentials";
+/** The support capability's secret-registry slice — aggregated into the shared accessor at startup. */
+const supportSecretsRegistry = r2CredentialsRegistry(SUPPORT_R2_SECRET);
+//#endregion
+export { SUPPORT_R2_SECRET, supportSecretsRegistry };

package/dist/seeds/example.d.ts

@@ -0,0 +1,3 @@
+import { type SeedSet } from "@pithy-sh/core/src/seed/seed";
+export declare const supportExampleSeed: SeedSet;
+//# sourceMappingURL=example.d.ts.map

package/dist/seeds/example.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"example.d.ts","sourceRoot":"","sources":["../../src/seeds/example.ts"],"names":[],"mappings":"AAIA,OAAO,EAA2B,KAAK,OAAO,EAAE,MAAM,8BAA8B,CAAC;AAgFrF,eAAO,MAAM,kBAAkB,EAAE,OA4S/B,CAAC"}

package/dist/seeds/example.js

@@ -0,0 +1,350 @@
+import { SupportClassification } from "../data/classification.js";
+import { SupportMessage } from "../data/message.js";
+import { SupportThread } from "../data/thread.js";
+import { SUPPORT_CLASSIFICATIONS_TABLE, SUPPORT_MESSAGES_TABLE, SUPPORT_THREADS_TABLE } from "../data/tables.js";
+import { EXAMPLE_ADA, EXAMPLE_ALAN, EXAMPLE_GRACE } from "@pithy-sh/core/src/seed/exampleIdentities";
+import { d1SeedGroup, defineSeed } from "@pithy-sh/core/src/seed/seed";
+//#region src/seeds/example.ts
+/**
+* Four conversations for the canonical example cast, spread across the shapes a dashboard has to
+* render.
+*
+* **Ada** is angry about a double charge — `billing`, `urgent`, and she is the one with a live Apple
+* subscription in the payments seed, so a thread view opened on her shows the linkage working end to
+* end rather than an empty panel. **Grace** cannot sign in — `account_access`, `normal`, two
+* messages, so the thread view has an actual conversation in it and the reply path has something
+* threaded to attach to. **Alan** sent a feature request that has been dealt with — `feature_request`,
+* `low`, `positive`, and **archived**, so the done pile is not empty on a fresh backend and the
+* archived filter is demonstrably doing something.
+*
+* **Grace again, from inside the app** — a `bug_report` filed through `POST /support/feedback`, so the
+* fixture carries both channels and the same person on each. That pairing is the demonstration: her
+* mail thread is linked to her account by an address in a header nobody proved, and her app thread is
+* linked by a session, and a console that renders the two identically has a bug this seed will show
+* you. It is also the only row carrying submission context, which is what a bug report knows and a
+* piece of mail cannot — and the only row carrying a `declaredCategory`, because it is the only sender
+* who was offered a chooser.
+*
+* **And it deliberately disagrees with itself.** Grace filed it under "something is missing" and the
+* model read the text and called it a bug, so `declaredCategory` is `feature_request` while `category`
+* is `bug_report`. That is the ordinary case rather than a contrived one — people file "X does not
+* work for me" under a missing feature constantly — and it is the row that makes the rendering mistake
+* visible before it ships: a console that shows one word, or shows the wrong one, has a bug this seed
+* will hand you. Every mail thread's is null, because nobody asked its sender anything.
+*
+* That is one row per priority, all four sentiments, four categories, both channels, both link
+* provenances, both a stated and an unstated category, and both sides of `archived` — the states
+* anything reading these tables has to handle, without anybody authoring a fixture first.
+*
+* **Everything is fixed — the ids and the clock.** `pithy seed` is `INSERT OR IGNORE`, so a generated
+* UUID would give Ada a second complaint on every run.
+*
+* **No attachments, and no raw messages.** Both would mean seeding R2 objects the D1 rows point at,
+* and a fixture whose rows name bytes that are not there is worse than one that claims less. The
+* classifications are seeded because they are the interesting half: a thread carries a model id, so
+* the seed shows what "which rows came from which model" looks like before anybody has run one.
+*
+* Composed in only when the project turns on `seed.includeExamples`, and only for `dev` and
+* `staging` — an example fixture never targets prod, whatever that setting says.
+*/
+/** Where this set sorts. After auth's users (100) and payments' purchases (250), which it links to. */
+const SUPPORT_EXAMPLE_SEED_ORDER = 260;
+/** Fixed ids, so the fixture is idempotent and a classification cannot drift off its thread. */
+const BILLING_THREAD_ID = "a1b2c3d4-0001-4a11-9c01-0e1f2a3b4c50";
+const ACCESS_THREAD_ID = "a1b2c3d4-0002-4a11-9c01-0e1f2a3b4c51";
+const FEATURE_THREAD_ID = "a1b2c3d4-0003-4a11-9c01-0e1f2a3b4c52";
+const APP_THREAD_ID = "a1b2c3d4-0004-4a11-9c01-0e1f2a3b4c53";
+const BILLING_MESSAGE_ID = "b1b2c3d4-0001-4a11-9c01-0e1f2a3b4c60";
+const ACCESS_MESSAGE_ID = "b1b2c3d4-0002-4a11-9c01-0e1f2a3b4c61";
+const ACCESS_REPLY_ID = "b1b2c3d4-0003-4a11-9c01-0e1f2a3b4c62";
+const FEATURE_MESSAGE_ID = "b1b2c3d4-0004-4a11-9c01-0e1f2a3b4c63";
+const APP_MESSAGE_ID = "b1b2c3d4-0005-4a11-9c01-0e1f2a3b4c64";
+const BILLING_CLASSIFICATION_ID = "c1b2c3d4-0001-4a11-9c01-0e1f2a3b4c70";
+const ACCESS_CLASSIFICATION_ID = "c1b2c3d4-0002-4a11-9c01-0e1f2a3b4c71";
+const FEATURE_CLASSIFICATION_ID = "c1b2c3d4-0003-4a11-9c01-0e1f2a3b4c72";
+const APP_CLASSIFICATION_ID = "c1b2c3d4-0004-4a11-9c01-0e1f2a3b4c73";
+/** The inbox these threads arrived on — a subdomain, which is the only safe shape for a real one. */
+const INBOX = "support@help.example.com";
+/** The model the seeded classifications claim to have come from. */
+const MODEL = "@cf/meta/llama-3.1-8b-instruct";
+/** One fixed moment. The demo is about state, not about a calendar. */
+const AT = /* @__PURE__ */ new Date("2026-01-10T09:00:00.000Z");
+const LATER = /* @__PURE__ */ new Date("2026-01-10T11:30:00.000Z");
+const ARCHIVED_AT = /* @__PURE__ */ new Date("2026-01-11T16:00:00.000Z");
+const supportExampleSeed = defineSeed({
+	name: "example",
+	order: SUPPORT_EXAMPLE_SEED_ORDER,
+	environments: ["dev", "staging"],
+	example: true,
+	d1: [
+		d1SeedGroup("app", SUPPORT_THREADS_TABLE, SupportThread, [
+			{
+				id: BILLING_THREAD_ID,
+				channel: "email",
+				inboxAddress: INBOX,
+				subject: "I was charged twice this month",
+				fromAddress: EXAMPLE_ADA.email,
+				fromName: EXAMPLE_ADA.name,
+				senderAuthenticated: true,
+				userId: EXAMPLE_ADA.id,
+				accountLinkSource: "email_address",
+				category: "billing",
+				priority: "urgent",
+				sentiment: "angry",
+				confidence: .94,
+				model: MODEL,
+				classifiedAt: AT,
+				archived: false,
+				archivedAt: null,
+				archivedBy: null,
+				messageCount: 1,
+				firstMessageAt: AT,
+				lastMessageAt: AT,
+				createdAt: AT,
+				updatedAt: AT
+			},
+			{
+				id: ACCESS_THREAD_ID,
+				channel: "email",
+				inboxAddress: INBOX,
+				subject: "Magic link never arrives",
+				fromAddress: EXAMPLE_GRACE.email,
+				fromName: EXAMPLE_GRACE.name,
+				senderAuthenticated: true,
+				userId: EXAMPLE_GRACE.id,
+				accountLinkSource: "email_address",
+				category: "account_access",
+				priority: "normal",
+				sentiment: "frustrated",
+				confidence: .81,
+				model: MODEL,
+				classifiedAt: AT,
+				archived: false,
+				archivedAt: null,
+				archivedBy: null,
+				messageCount: 2,
+				firstMessageAt: AT,
+				lastMessageAt: LATER,
+				createdAt: AT,
+				updatedAt: LATER
+			},
+			{
+				id: FEATURE_THREAD_ID,
+				channel: "email",
+				inboxAddress: INBOX,
+				subject: "Could you add CSV export?",
+				fromAddress: EXAMPLE_ALAN.email,
+				fromName: EXAMPLE_ALAN.name,
+				senderAuthenticated: true,
+				userId: EXAMPLE_ALAN.id,
+				accountLinkSource: "email_address",
+				category: "feature_request",
+				priority: "low",
+				sentiment: "positive",
+				confidence: .88,
+				model: MODEL,
+				classifiedAt: AT,
+				archived: true,
+				archivedAt: ARCHIVED_AT,
+				archivedBy: "example-dashboard",
+				messageCount: 1,
+				firstMessageAt: AT,
+				lastMessageAt: AT,
+				createdAt: AT,
+				updatedAt: ARCHIVED_AT
+			},
+			{
+				id: APP_THREAD_ID,
+				channel: "app",
+				inboxAddress: INBOX,
+				subject: "Export button does nothing on the reports screen",
+				fromAddress: EXAMPLE_GRACE.email,
+				fromName: EXAMPLE_GRACE.name,
+				senderAuthenticated: true,
+				userId: EXAMPLE_GRACE.id,
+				accountLinkSource: "session",
+				declaredCategory: "feature_request",
+				category: "bug_report",
+				priority: "normal",
+				sentiment: "neutral",
+				confidence: .91,
+				model: MODEL,
+				classifiedAt: AT,
+				archived: false,
+				archivedAt: null,
+				archivedBy: null,
+				messageCount: 1,
+				firstMessageAt: LATER,
+				lastMessageAt: LATER,
+				createdAt: LATER,
+				updatedAt: LATER
+			}
+		]),
+		d1SeedGroup("app", SUPPORT_MESSAGES_TABLE, SupportMessage, [
+			{
+				id: BILLING_MESSAGE_ID,
+				threadId: BILLING_THREAD_ID,
+				direction: "inbound",
+				channel: "email",
+				submittedByUserId: null,
+				context: null,
+				mimeMessageId: "seed-billing-1@example.com",
+				mimeInReplyTo: null,
+				mimeReferences: null,
+				fromAddress: EXAMPLE_ADA.email,
+				fromName: EXAMPLE_ADA.name,
+				toAddress: INBOX,
+				subject: "I was charged twice this month",
+				textBody: "My card shows two charges for the same subscription on the 3rd. I have only ever had one account. Please refund the duplicate.",
+				htmlBody: null,
+				emailJobId: null,
+				rawKey: null,
+				rawBytes: null,
+				receivedAt: AT,
+				createdAt: AT
+			},
+			{
+				id: ACCESS_MESSAGE_ID,
+				threadId: ACCESS_THREAD_ID,
+				direction: "inbound",
+				channel: "email",
+				submittedByUserId: null,
+				context: null,
+				mimeMessageId: "seed-access-1@example.com",
+				mimeInReplyTo: null,
+				mimeReferences: null,
+				fromAddress: EXAMPLE_GRACE.email,
+				fromName: EXAMPLE_GRACE.name,
+				toAddress: INBOX,
+				subject: "Magic link never arrives",
+				textBody: "I have asked for a sign-in link four times today and none of them have arrived. I checked spam. Is something broken?",
+				htmlBody: null,
+				emailJobId: null,
+				rawKey: null,
+				rawBytes: null,
+				receivedAt: AT,
+				createdAt: AT
+			},
+			{
+				id: ACCESS_REPLY_ID,
+				threadId: ACCESS_THREAD_ID,
+				direction: "outbound",
+				channel: "email",
+				submittedByUserId: null,
+				context: null,
+				mimeMessageId: null,
+				mimeInReplyTo: "seed-access-1@example.com",
+				mimeReferences: ["seed-access-1@example.com"],
+				fromAddress: INBOX,
+				fromName: null,
+				toAddress: EXAMPLE_GRACE.email,
+				subject: "Re: Magic link never arrives",
+				textBody: "Hi Grace,\n\nI found the problem — your address had bounced earlier in the week and was on our suppression list. I have cleared it. Try again and it should arrive within a minute.\n\nSorry for the trouble.\n",
+				htmlBody: null,
+				emailJobId: "seed-email-job-access-1",
+				rawKey: null,
+				rawBytes: null,
+				receivedAt: LATER,
+				createdAt: LATER
+			},
+			{
+				id: FEATURE_MESSAGE_ID,
+				threadId: FEATURE_THREAD_ID,
+				direction: "inbound",
+				channel: "email",
+				submittedByUserId: null,
+				context: null,
+				mimeMessageId: "seed-feature-1@example.com",
+				mimeInReplyTo: null,
+				mimeReferences: null,
+				fromAddress: EXAMPLE_ALAN.email,
+				fromName: EXAMPLE_ALAN.name,
+				toAddress: INBOX,
+				subject: "Could you add CSV export?",
+				textBody: "Loving the product. The one thing I miss is being able to export my data as CSV for a spreadsheet. No rush.",
+				htmlBody: null,
+				emailJobId: null,
+				rawKey: null,
+				rawBytes: null,
+				receivedAt: AT,
+				createdAt: AT
+			},
+			{
+				id: APP_MESSAGE_ID,
+				threadId: APP_THREAD_ID,
+				direction: "inbound",
+				channel: "app",
+				submittedByUserId: EXAMPLE_GRACE.id,
+				context: {
+					screen: "reports",
+					appVersion: "2.4.1",
+					platform: "web",
+					environment: "prod",
+					locale: "en-GB"
+				},
+				mimeMessageId: `${APP_MESSAGE_ID}@help.example.com`,
+				mimeInReplyTo: null,
+				mimeReferences: null,
+				fromAddress: EXAMPLE_GRACE.email,
+				fromName: EXAMPLE_GRACE.name,
+				toAddress: INBOX,
+				subject: "Export button does nothing on the reports screen",
+				textBody: "I press Export on the reports screen and nothing happens. No download, no error. It worked last week. Chrome, if that helps.",
+				htmlBody: null,
+				emailJobId: null,
+				rawKey: null,
+				rawBytes: null,
+				receivedAt: LATER,
+				createdAt: LATER
+			}
+		]),
+		d1SeedGroup("app", SUPPORT_CLASSIFICATIONS_TABLE, SupportClassification, [
+			{
+				id: BILLING_CLASSIFICATION_ID,
+				threadId: BILLING_THREAD_ID,
+				messageId: BILLING_MESSAGE_ID,
+				category: "billing",
+				priority: "urgent",
+				sentiment: "angry",
+				confidence: .94,
+				model: MODEL,
+				createdAt: AT
+			},
+			{
+				id: ACCESS_CLASSIFICATION_ID,
+				threadId: ACCESS_THREAD_ID,
+				messageId: ACCESS_MESSAGE_ID,
+				category: "account_access",
+				priority: "normal",
+				sentiment: "frustrated",
+				confidence: .81,
+				model: MODEL,
+				createdAt: AT
+			},
+			{
+				id: APP_CLASSIFICATION_ID,
+				threadId: APP_THREAD_ID,
+				messageId: APP_MESSAGE_ID,
+				category: "bug_report",
+				priority: "normal",
+				sentiment: "neutral",
+				confidence: .91,
+				model: MODEL,
+				createdAt: LATER
+			},
+			{
+				id: FEATURE_CLASSIFICATION_ID,
+				threadId: FEATURE_THREAD_ID,
+				messageId: FEATURE_MESSAGE_ID,
+				category: "feature_request",
+				priority: "low",
+				sentiment: "positive",
+				confidence: .88,
+				model: MODEL,
+				createdAt: AT
+			}
+		])
+	]
+});
+//#endregion
+export { supportExampleSeed };

package/dist/store/paging.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The inbox page bounds, in the one module that has no reason to import anything (#430).
+ *
+ * `http/schemas.ts` bounds a caller's `limit` with the same number the reader clamps to, and it used to
+ * read it out of `store/threads.ts` — the Kysely reader, which brings `kysely`, `kysely-d1` and
+ * `@cloudflare/workers-types` with it. A request schema is a client's business: a management client
+ * building a call must be able to compile the shape it may send, in a browser, with no Worker types in
+ * reach. So the two numbers moved and the reader kept the query.
+ *
+ * **Both moved, not only the one the schema needs.** They are read together — a default clamped into a
+ * maximum, on one line, in two queries — and a pair split across two modules is how the next person
+ * picks the wrong one.
+ */
+/** How many threads a page holds by default. */
+export declare const DEFAULT_PAGE_SIZE = 25;
+/** The most a caller may ask for in one page. */
+export declare const MAX_PAGE_SIZE = 100;
+//# sourceMappingURL=paging.d.ts.map

package/dist/store/paging.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"paging.d.ts","sourceRoot":"","sources":["../../src/store/paging.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;GAYG;AAEH,gDAAgD;AAChD,eAAO,MAAM,iBAAiB,KAAK,CAAC;AAEpC,iDAAiD;AACjD,eAAO,MAAM,aAAa,MAAM,CAAC"}

package/dist/store/paging.js

@@ -0,0 +1,20 @@
+//#region src/store/paging.ts
+/**
+* The inbox page bounds, in the one module that has no reason to import anything (#430).
+*
+* `http/schemas.ts` bounds a caller's `limit` with the same number the reader clamps to, and it used to
+* read it out of `store/threads.ts` — the Kysely reader, which brings `kysely`, `kysely-d1` and
+* `@cloudflare/workers-types` with it. A request schema is a client's business: a management client
+* building a call must be able to compile the shape it may send, in a browser, with no Worker types in
+* reach. So the two numbers moved and the reader kept the query.
+*
+* **Both moved, not only the one the schema needs.** They are read together — a default clamped into a
+* maximum, on one line, in two queries — and a pair split across two modules is how the next person
+* picks the wrong one.
+*/
+/** How many threads a page holds by default. */
+const DEFAULT_PAGE_SIZE = 25;
+/** The most a caller may ask for in one page. */
+const MAX_PAGE_SIZE = 100;
+//#endregion
+export { DEFAULT_PAGE_SIZE, MAX_PAGE_SIZE };

package/dist/store/search.d.ts

@@ -0,0 +1,67 @@
+import { type Expression, type SqlBool } from "kysely";
+import { type SupportDatabase } from "../data/tables";
+/**
+ * Turn a user's words into an FTS5 MATCH expression.
+ *
+ * Every token is quoted and the whole thing is ANDed. Quoting is what stops FTS5's own query syntax
+ * from leaking through: a bare `NOT`, `OR`, `*` or `(` is an operator to FTS5, so a customer whose
+ * surname is a keyword — or anyone deliberately probing — would otherwise change the shape of the
+ * query rather than search for a word. This is the same "input is data, never syntax" rule the rest
+ * of the package applies to model output and to HTML.
+ */
+export declare function ftsQuery(term: string): string;
+/** Whether a term has anything searchable left after tokenizing. */
+export declare function isSearchable(term: string, fts: boolean): boolean;
+/**
+ * A predicate matching threads whose messages contain `term`.
+ *
+ * Correlated on the thread id so it drops into a `where` beside every other filter. The subquery is
+ * `exists`, so it stops at the first matching message rather than counting them.
+ */
+export declare function searchPredicate(term: string, options: {
+    fts: boolean;
+}): Expression<SqlBool>;
+/**
+ * Add a message to the full-text index, replacing any row already there for it.
+ *
+ * **Remove-then-insert, not a bare insert** — the same shape the CMS `syncFts` uses, and for the
+ * reason application-managed indexes always need it: an FTS5 table has no primary key and no unique
+ * constraint to lean on, so a second call for the same message would silently add a second copy and
+ * the thread would start appearing twice in its own search results. Making the write idempotent means
+ * a retry, a reindex, and a first index are all the same operation, which is the property every other
+ * write path in this repo is built on.
+ *
+ * Best-effort by contract: a failed index write must never lose a customer's message, so the caller
+ * logs and carries on — the row is still there, still readable, still repairable by
+ * {@link reindexThread}, and only missing from one search box.
+ */
+export declare function indexMessage(db: SupportDatabase, entry: {
+    threadId: string;
+    messageId: string;
+    subject: string;
+    body: string;
+}): Promise<void>;
+/**
+ * Rebuild the index for one thread — delete its rows, then re-add every message.
+ *
+ * The repair path for the failure mode application-side indexing has and triggers would not: a
+ * message stored while the index write failed. Also what a reindex after a tokenizer change runs.
+ */
+export declare function reindexThread(db: SupportDatabase, threadId: string): Promise<number>;
+/**
+ * Rebuild the whole index from the messages table, in pages.
+ *
+ * **Creating the index is not the same as populating it**, and that gap is the one failure a search
+ * box must not have: an adopter who turns `search.fts` on after mail already exists gets an empty
+ * virtual table, and because the table now *exists* the `LIKE` fallback never fires — so the inbox
+ * answers "no matches" for a term that is demonstrably in the body. Silently returning nothing is
+ * worse than returning slowly, so provisioning backfills immediately after it creates.
+ *
+ * Paged on `(receivedAt, id)` rather than an offset, for the same reason the inbox is: rows arriving
+ * during a long backfill would shift an offset underneath it and skip messages.
+ */
+export declare function reindexAll(db: SupportDatabase, options?: {
+    pageSize?: number;
+    onProgress?: (indexed: number) => void;
+}): Promise<number>;
+//# sourceMappingURL=search.d.ts.map

package/dist/store/search.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"search.d.ts","sourceRoot":"","sources":["../../src/store/search.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,KAAK,UAAU,EAAE,KAAK,OAAO,EAAO,MAAM,QAAQ,CAAC;AAC5D,OAAO,EAA0B,KAAK,eAAe,EAAE,MAAM,gBAAgB,CAAC;AA+B9E;;;;;;;;GAQG;AACH,wBAAgB,QAAQ,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAS7C;AAED,oEAAoE;AACpE,wBAAgB,YAAY,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,EAAE,OAAO,GAAG,OAAO,CAEhE;AAED;;;;;GAKG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE;IAAE,GAAG,EAAE,OAAO,CAAA;CAAE,GAAG,UAAU,CAAC,OAAO,CAAC,CAkB5F;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAsB,YAAY,CAChC,EAAE,EAAE,eAAe,EACnB,KAAK,EAAE;IAAE,QAAQ,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAC5E,OAAO,CAAC,IAAI,CAAC,CAMf;AAED;;;;;GAKG;AACH,wBAAsB,aAAa,CAAC,EAAE,EAAE,eAAe,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAkB1F;AAED;;;;;;;;;;;GAWG;AACH,wBAAsB,UAAU,CAC9B,EAAE,EAAE,eAAe,EACnB,OAAO,GAAE;IAAE,QAAQ,CAAC,EAAE,MAAM,CAAC;IAAC,UAAU,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,KAAK,IAAI,CAAA;CAAO,GAC1E,OAAO,CAAC,MAAM,CAAC,CA4CjB"}