@pithy-sh/support 0.5.1 → 0.6.0

package/dist/version.generated.d.ts

@@ -3,5 +3,5 @@
 /** This package's npm name — the join key against a release feed. */
 export declare const PACKAGE_NAME = "@pithy-sh/support";
 /** This package's version, stamped from its own package.json at generation time. */
-export declare const PACKAGE_VERSION = "0.5.1";
+export declare const PACKAGE_VERSION = "0.6.0";
 //# sourceMappingURL=version.generated.d.ts.map

package/dist/version.generated.js

@@ -4,6 +4,6 @@
 /** This package's npm name — the join key against a release feed. */
 const PACKAGE_NAME = "@pithy-sh/support";
 /** This package's version, stamped from its own package.json at generation time. */
-const PACKAGE_VERSION = "0.5.1";
+const PACKAGE_VERSION = "0.6.0";
 //#endregion
 export { PACKAGE_NAME, PACKAGE_VERSION };

package/dist/workflows/specs.d.ts

@@ -24,6 +24,19 @@ export declare const SupportClassifyParams: z.ZodObject<{
     messageId: z.ZodString;
 }, z.core.$strip>;
 export type SupportClassifyParams = z.infer<typeof SupportClassifyParams>;
+/**
+ * One re-embed of the semantic message index, started by `pithy vector reprocess --index support-messages`.
+ *
+ * The parameters are the ones `pithy vector reprocess` sends every index, so the CLI dispatches a capability's
+ * index exactly as it dispatches one `vector()` owns. There is no `filter`: the vectors carry no metadata to
+ * filter on.
+ */
+export declare const SupportReprocessParams: z.ZodObject<{
+    index: z.ZodLiteral<"support-messages">;
+    all: z.ZodOptional<z.ZodBoolean>;
+    pageSize: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type SupportReprocessParams = z.infer<typeof SupportReprocessParams>;
 /** Support's durable jobs, keyed by job name. The key is the second segment of the `support/<job>` dispatch key. */
 export declare const supportWorkflows: {
     readonly classify: {
@@ -34,6 +47,16 @@ export declare const supportWorkflows: {
         }, z.core.$strip>;
         readonly optional: true;
     };
+    readonly reprocess: {
+        readonly binding: "SUPPORT_REPROCESS";
+        readonly className: "SupportReprocessWorkflow";
+        readonly params: z.ZodObject<{
+            index: z.ZodLiteral<"support-messages">;
+            all: z.ZodOptional<z.ZodBoolean>;
+            pageSize: z.ZodOptional<z.ZodNumber>;
+        }, z.core.$strip>;
+        readonly optional: true;
+    };
 };
 /**
  * Support's jobs as a dispatch registry, keyed `support/<job>`. Built here rather than through

package/dist/workflows/specs.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"specs.d.ts","sourceRoot":"","sources":["../../src/workflows/specs.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,gBAAgB,EAAmB,MAAM,kCAAkC,CAAC;AAC1F,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;GAcG;AAEH,uGAAuG;AACvG,eAAO,MAAM,kBAAkB,YAAY,CAAC;AAE5C,iCAAiC;AACjC,eAAO,MAAM,qBAAqB;;iBASsE,CAAC;AACzG,MAAM,MAAM,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAE1E,oHAAoH;AACpH,eAAO,MAAM,gBAAgB;;iBAEzB,OAAO,EAAE,kBAAkB;iBAC3B,SAAS,EAAE,yBAAyB;iBACpC,MAAM;;;iBACN,QAAQ;;CAEwB,CAAC;AAErC;;;;;GAKG;AACH,eAAO,MAAM,uBAAuB,EAAE,gBAKrC,CAAC"}
+{"version":3,"file":"specs.d.ts","sourceRoot":"","sources":["../../src/workflows/specs.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,gBAAgB,EAAmB,MAAM,kCAAkC,CAAC;AAC1F,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;GAcG;AAEH,uGAAuG;AACvG,eAAO,MAAM,kBAAkB,YAAY,CAAC;AAE5C,iCAAiC;AACjC,eAAO,MAAM,qBAAqB;;iBASsE,CAAC;AACzG,MAAM,MAAM,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAE1E;;;;;;GAMG;AACH,eAAO,MAAM,sBAAsB;;;;iBAgB+C,CAAC;AACnF,MAAM,MAAM,sBAAsB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAE5E,oHAAoH;AACpH,eAAO,MAAM,gBAAgB;;iBAEzB,OAAO,EAAE,kBAAkB;iBAC3B,SAAS,EAAE,yBAAyB;iBACpC,MAAM;;;iBACN,QAAQ;;;iBAKR,OAAO,EAAE,mBAAmB;iBAC5B,SAAS,EAAE,0BAA0B;iBACrC,MAAM;;;;;iBACN,QAAQ;;CAEwB,CAAC;AAErC;;;;;GAKG;AACH,eAAO,MAAM,uBAAuB,EAAE,gBAKrC,CAAC"}

package/dist/workflows/specs.js

@@ -22,13 +22,33 @@ import { workflowKey } from "@pithy-sh/core/src/workflow/naming";
 const SUPPORT_CAPABILITY = "support";
 /** Which message to classify. */
 const SupportClassifyParams = z.object({ messageId: z.string().min(1).describe("The `pithy_support_messages.id` to classify. The Workflow reads that message, asks the model about it, appends a classification row, and denormalizes the answer onto its thread.") }).describe("The instance parameters of the classification Workflow — the one message it runs against.");
+/**
+* One re-embed of the semantic message index, started by `pithy vector reprocess --index support-messages`.
+*
+* The parameters are the ones `pithy vector reprocess` sends every index, so the CLI dispatches a capability's
+* index exactly as it dispatches one `vector()` owns. There is no `filter`: the vectors carry no metadata to
+* filter on.
+*/
+const SupportReprocessParams = z.object({
+	index: z.literal("support-messages").describe("The index to re-embed. Support declares one, `support-messages`."),
+	all: z.boolean().optional().describe("Re-embed every inbound message, not only the ones whose stamp differs from the configured model. What a fresh index's backfill runs."),
+	pageSize: z.number().int().min(1).optional().describe("Messages per Workflow step. Defaults to the Vectorize upsert ceiling of 1,000.")
+}).describe("The instance parameters of a re-embed of the support message index.");
 /** Support's durable jobs, keyed by job name. The key is the second segment of the `support/<job>` dispatch key. */
-const supportWorkflows = { classify: {
-	binding: "SUPPORT_CLASSIFY",
-	className: "SupportClassifyWorkflow",
-	params: SupportClassifyParams,
-	optional: true
-} };
+const supportWorkflows = {
+	classify: {
+		binding: "SUPPORT_CLASSIFY",
+		className: "SupportClassifyWorkflow",
+		params: SupportClassifyParams,
+		optional: true
+	},
+	reprocess: {
+		binding: "SUPPORT_REPROCESS",
+		className: "SupportReprocessWorkflow",
+		params: SupportReprocessParams,
+		optional: true
+	}
+};
 /**
 * Support's jobs as a dispatch registry, keyed `support/<job>`. Built here rather than through
 * `composeWorkflows` because the inbound handler dispatches from inside the capability, before any
@@ -45,4 +65,4 @@ const supportWorkflowRegistry = Object.fromEntries(Object.entries(supportWorkflo
 	}];
 }));
 //#endregion
-export { SUPPORT_CAPABILITY, SupportClassifyParams, supportWorkflowRegistry, supportWorkflows };
+export { SUPPORT_CAPABILITY, SupportClassifyParams, SupportReprocessParams, supportWorkflowRegistry, supportWorkflows };

package/dist/workflows/worker.d.ts

@@ -2,7 +2,10 @@
 // SPDX-License-Identifier: MIT
 import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from "cloudflare:workers";
 import type { D1Database } from "@cloudflare/workers-types";
+import type { VectorStore } from "@pithy-sh/vector/src/index/index";
+import { type ReprocessReport } from "@pithy-sh/vector/src/workflows/reprocess";
 import type { SupportAi } from "../ai/classify";
+import { SupportReprocessParams } from "./specs";
 /**
  * The prebuilt support worker. `pithy support provision` deploys one per environment; the adopter
  * authors no code for it. It hosts the classification Workflow — a thin durable shell around the
@@ -23,12 +26,14 @@ import type { SupportAi } from "../ai/classify";
  * refusal it exports is the honest body for a host with no request surface; see
  * `@pithy-sh/core/src/workflow/hostEntry`.
  */
-/** The support worker's env: the app database, the AI binding, and the serialized config. */
+/** The support worker's env: the app database, the AI binding, the message index, and the serialized config. */
 export interface SupportWorkerEnv {
     /** The app database the support tables live in. */
     DB: D1Database;
-    /** The Workers AI binding. */
+    /** The Workers AI binding — classification and embedding both run on it. */
     AI: SupportAi;
+    /** The semantic message index. Bound only when `search.semantic` is on. */
+    SUPPORT_VECTORIZE?: VectorStore;
     /** The resolved support config as a JSON string, filled at provision. */
     SUPPORT_CONFIG?: string;
 }
@@ -40,6 +45,14 @@ export declare class SupportClassifyWorkflow extends WorkflowEntrypoint<SupportW
         messageId: string;
     }>, step: WorkflowStep): Promise<void>;
 }
+/**
+ * Re-embed the semantic message index — `@pithy-sh/vector`'s own reprocess orchestration, over support's
+ * `DocumentStore`, one journalled page per step. `pithy vector reprocess --index support-messages` starts it,
+ * and so does `pithy support provision` once, to backfill an index it just created.
+ */
+export declare class SupportReprocessWorkflow extends WorkflowEntrypoint<SupportWorkerEnv, SupportReprocessParams> {
+    run(event: WorkflowEvent<SupportReprocessParams>, step: WorkflowStep): Promise<ReprocessReport>;
+}
 /**
  * The module's default export, and therefore its format. See `hostEntry` for why a Workflow host needs
  * one at all, and why this one refuses rather than being empty: nothing reaches this worker over HTTP —

package/dist/workflows/worker.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"worker.d.ts","sourceRoot":"","sources":["../../src/workflows/worker.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,kBAAkB,EAAE,KAAK,aAAa,EAAE,KAAK,YAAY,EAAE,MAAM,oBAAoB,CAAC;AAE/F,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,2BAA2B,CAAC;AAG5D,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,gBAAgB,CAAC;AAQhD;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,6FAA6F;AAC7F,MAAM,WAAW,gBAAgB;IAC/B,mDAAmD;IACnD,EAAE,EAAE,UAAU,CAAC;IACf,8BAA8B;IAC9B,EAAE,EAAE,SAAS,CAAC;IACd,yEAAyE;IACzE,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB;AAED,wDAAwD;AACxD,qBAAa,uBAAwB,SAAQ,kBAAkB,CAAC,gBAAgB,EAAE;IAAE,SAAS,EAAE,MAAM,CAAA;CAAE,CAAC;IACvF,GAAG,CAAC,KAAK,EAAE,aAAa,CAAC;QAAE,SAAS,EAAE,MAAM,CAAA;KAAE,CAAC,EAAE,IAAI,EAAE,YAAY,GAAG,OAAO,CAAC,IAAI,CAAC,CAwBjG;CACF;AAED;;;;GAIG"}
+{"version":3,"file":"worker.d.ts","sourceRoot":"","sources":["../../src/workflows/worker.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,kBAAkB,EAAE,KAAK,aAAa,EAAE,KAAK,YAAY,EAAE,MAAM,oBAAoB,CAAC;AAE/F,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,2BAA2B,CAAC;AAM5D,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,kCAAkC,CAAC;AACpE,OAAO,EAAE,KAAK,eAAe,EAAkB,MAAM,0CAA0C,CAAC;AAChG,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,gBAAgB,CAAC;AAShD,OAAO,EAAsB,sBAAsB,EAAE,MAAM,SAAS,CAAC;AAErE;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,gHAAgH;AAChH,MAAM,WAAW,gBAAgB;IAC/B,mDAAmD;IACnD,EAAE,EAAE,UAAU,CAAC;IACf,4EAA4E;IAC5E,EAAE,EAAE,SAAS,CAAC;IACd,2EAA2E;IAC3E,iBAAiB,CAAC,EAAE,WAAW,CAAC;IAChC,yEAAyE;IACzE,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB;AAOD,wDAAwD;AACxD,qBAAa,uBAAwB,SAAQ,kBAAkB,CAAC,gBAAgB,EAAE;IAAE,SAAS,EAAE,MAAM,CAAA;CAAE,CAAC;IACvF,GAAG,CAAC,KAAK,EAAE,aAAa,CAAC;QAAE,SAAS,EAAE,MAAM,CAAA;KAAE,CAAC,EAAE,IAAI,EAAE,YAAY,GAAG,OAAO,CAAC,IAAI,CAAC,CA+CjG;CACF;AAED;;;;GAIG;AACH,qBAAa,wBAAyB,SAAQ,kBAAkB,CAAC,gBAAgB,EAAE,sBAAsB,CAAC;IACzF,GAAG,CAAC,KAAK,EAAE,aAAa,CAAC,sBAAsB,CAAC,EAAE,IAAI,EAAE,YAAY,GAAG,OAAO,CAAC,eAAe,CAAC,CA6B7G;CACF;AAED;;;;GAIG"}

package/dist/workflows/worker.js

@@ -3,18 +3,28 @@
 import { SupportConfig } from "../config/config.js";
 import { resolveCategories } from "../data/categories.js";
 import { supportDatabase } from "../data/tables.js";
-import { SUPPORT_CAPABILITY } from "./specs.js";
+import { supportMessageIndex } from "../semantic/messageIndex.js";
+import { SUPPORT_CAPABILITY, SupportReprocessParams } from "./specs.js";
 import { runClassification } from "./classify.js";
+import { supportMessageDocuments } from "../semantic/documents.js";
+import { runEmbedding } from "../semantic/embed.js";
 import { supportWorkflowRetry } from "./retryPolicy.js";
+import { pithyCommandOf } from "@pithy-sh/core/src/cli/command";
+import { createWorkerLogger } from "@pithy-sh/core/src/logger/worker";
 import { WorkflowEntrypoint } from "cloudflare:workers";
 import { NonRetryableError } from "cloudflare:workflows";
 import { classifiedSteps } from "@pithy-sh/core/src/workflow/faults";
 import { workflowHostEntry } from "@pithy-sh/core/src/workflow/hostEntry";
+import { reprocessIndex } from "@pithy-sh/vector/src/workflows/reprocess";
 //#region src/workflows/worker.ts
+/** Parse the config this worker was deployed with. Absent falls back to the defaults. */
+function workerConfig(env) {
+	return SupportConfig.parse(env.SUPPORT_CONFIG ? JSON.parse(env.SUPPORT_CONFIG) : {});
+}
 /** Classify one stored message and write the result. */
 var SupportClassifyWorkflow = class extends WorkflowEntrypoint {
 	async run(event, step) {
-		const config = SupportConfig.parse(this.env.SUPPORT_CONFIG ? JSON.parse(this.env.SUPPORT_CONFIG) : {});
+		const config = workerConfig(this.env);
 		const deps = {
 			db: supportDatabase(this.env.DB),
 			ai: this.env.AI,
@@ -24,9 +34,43 @@ var SupportClassifyWorkflow = class extends WorkflowEntrypoint {
 			newId: () => crypto.randomUUID(),
 			now: () => /* @__PURE__ */ new Date()
 		};
-		await classifiedSteps(step, supportWorkflowRetry, NonRetryableError).do(`classify-${event.payload.messageId}`, async () => {
+		if (config.ai.enabled) await classifiedSteps(step, supportWorkflowRetry, NonRetryableError).do(`classify-${event.payload.messageId}`, async () => {
 			await runClassification(deps, event.payload.messageId);
 		});
+		const index = supportMessageIndex(config.search);
+		if (index) await classifiedSteps(step, supportWorkflowRetry, NonRetryableError).do(`embed-${event.payload.messageId}`, () => runEmbedding({
+			db: deps.db,
+			ai: this.env.AI,
+			store: this.env.SUPPORT_VECTORIZE,
+			index,
+			now: () => /* @__PURE__ */ new Date(),
+			log: createWorkerLogger({ name: `${SUPPORT_CAPABILITY}:embed` })
+		}, event.payload.messageId));
+	}
+};
+/**
+* Re-embed the semantic message index — `@pithy-sh/vector`'s own reprocess orchestration, over support's
+* `DocumentStore`, one journalled page per step. `pithy vector reprocess --index support-messages` starts it,
+* and so does `pithy support provision` once, to backfill an index it just created.
+*/
+var SupportReprocessWorkflow = class extends WorkflowEntrypoint {
+	async run(event, step) {
+		const params = SupportReprocessParams.parse(event.payload);
+		const index = supportMessageIndex(workerConfig(this.env).search);
+		if (!index) throw new NonRetryableError("support/reprocess: search.semantic is off in this worker's config, so there is no message index to re-embed");
+		const store = this.env.SUPPORT_VECTORIZE;
+		if (!store) throw new NonRetryableError(`support/reprocess: the SUPPORT_VECTORIZE binding is absent; run \`${pithyCommandOf("support provision", {}, { runtime: true })}\` to bind the index`);
+		return reprocessIndex({
+			documents: supportMessageDocuments(supportDatabase(this.env.DB), { store }),
+			store,
+			ai: this.env.AI,
+			index,
+			indexName: params.index,
+			now: () => /* @__PURE__ */ new Date()
+		}, classifiedSteps(step, supportWorkflowRetry, NonRetryableError), {
+			...params.all !== void 0 ? { all: params.all } : {},
+			...params.pageSize !== void 0 ? { pageSize: params.pageSize } : {}
+		});
 	}
 };
 /**
@@ -36,4 +80,4 @@ var SupportClassifyWorkflow = class extends WorkflowEntrypoint {
 */
 var worker_default = workflowHostEntry(SUPPORT_CAPABILITY);
 //#endregion
-export { SupportClassifyWorkflow, worker_default as default };
+export { SupportClassifyWorkflow, SupportReprocessWorkflow, worker_default as default };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pithy-sh/support",
-  "version": "0.5.1",
+  "version": "0.6.0",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -40,12 +40,13 @@
     "tldts": "^7.4.10"
   },
   "peerDependencies": {
-    "@pithy-sh/auth": "^0.11.0",
-    "@pithy-sh/core": "^0.13.0",
-    "@pithy-sh/email": "^0.7.0",
-    "@pithy-sh/payments": "^0.6.1",
-    "@pithy-sh/secrets": "^0.6.1",
-    "@pithy-sh/storage": "^0.6.0",
+    "@pithy-sh/auth": "^0.12.0",
+    "@pithy-sh/core": "^0.14.0",
+    "@pithy-sh/email": "^0.8.0",
+    "@pithy-sh/payments": "^0.7.0",
+    "@pithy-sh/secrets": "^0.6.2",
+    "@pithy-sh/storage": "^0.7.0",
+    "@pithy-sh/vector": "^0.5.2",
     "hono": "^4.13.2",
     "kysely": "^0.29.0",
     "zod": "^4.4.0"
@@ -67,6 +68,7 @@
     "@pithy-sh/secrets": "workspace:*",
     "@pithy-sh/storage": "workspace:*",
     "@pithy-sh/tsconfig": "workspace:*",
+    "@pithy-sh/vector": "workspace:*",
     "@types/node": "^22.15.0",
     "@vitest/coverage-v8": "^4.1.0",
     "hono": "^4.13.2",

package/pithy.manifest.json

@@ -10,25 +10,43 @@
       "job": "classify",
       "className": "SupportClassifyWorkflow",
       "optional": true
+    },
+    {
+      "type": "workflow",
+      "name": "SUPPORT_REPROCESS",
+      "job": "reprocess",
+      "className": "SupportReprocessWorkflow",
+      "optional": true
+    },
+    { "type": "vectorize", "name": "SUPPORT_VECTORIZE", "optional": true, "remote": true },
+    { "type": "ai", "name": "AI", "optional": true, "remote": true },
+    {
+      "type": "durable_object",
+      "name": "PRESENCE_ROOMS",
+      "className": "PresenceRoom",
+      "classModule": "@pithy-sh/core/src/presence/durableObject"
     }
   ],
   "peerCapabilities": ["secrets"],
   "optionalCapabilities": ["controlplane", "email", "auth", "payments", "audit", "storage"],
   "migrationNamespace": "support",
-  "whenToEnable": "A support inbox that lands mail — and your signed-in users' own reports — in your own D1, classifies both on your own Workers AI binding, and links each sender to the account and purchases your app already knows about. Support is the employee a solo developer cannot hire, and every piece needed to build it was already in the catalog. Mail arrives through Cloudflare Email Routing, is parsed (multipart and attachments included), threaded on In-Reply-To and References so a conversation stays one conversation, and classified three ways at once — category, priority, sentiment — which makes a sortable inbox rather than a labelled one. The taxonomy is federated: eight categories ship, and you add your own with defineSupportCategories. Classification runs on your binding, so the inference lands on your bill and your customers' support mail never leaves your infrastructure. Everything is derived from immutable mail: a wrong classification is recomputed, not repaired, and there is no assignment and no status workflow, because that is a helpdesk product and this is not one. Your signed-in users reach the same inbox without leaving the app: POST /support/feedback opens a thread behind requireAuth(), into the same table, the same classifier, and the same taxonomy — no second inbox, no second console. That channel is where the mail path's hardest problem does not exist, because there is no From: header to spoof: the session is the identity, so the thread records whether its account link was proven by a session or merely matched against an address, and a console can tell the two apart. Replies go out through @pithy-sh/email carrying your domain, your DKIM, and correct threading headers — which only the Worker can set — whichever channel the question arrived on. The admin surface is control-plane only and default-denied; the three in-app routes answer to a user's session and to no scope at all. **Cloudflare Email Routing takes over a zone's MX**, so use a subdomain (support@help.yourdomain.com) and never your apex, or you will move your real mail off your existing provider.",
+  "devSecrets": [{ "name": "presence-ticket-key", "devValue": "random" }],
+  "whenToEnable": "A support inbox that lands mail — and your signed-in users' own reports — in your own D1, classifies both on your own Workers AI binding, and links each sender to the account and purchases your app already knows about. Support is the employee a solo developer cannot hire, and every piece needed to build it was already in the catalog. Mail arrives through Cloudflare Email Routing, is parsed (multipart and attachments included), threaded on In-Reply-To and References so a conversation stays one conversation, and classified three ways at once — category, priority, sentiment — which makes a sortable inbox rather than a labelled one. The taxonomy is federated: eight categories ship, and you add your own with defineSupportCategories. Classification runs on your binding, so the inference lands on your bill and your customers' support mail never leaves your infrastructure. Everything is derived from immutable mail: a wrong classification is recomputed, not repaired, and there is no status workflow, because that is a helpdesk product and this is not one. What a shared inbox does need, it has: a thread can be assigned to somebody, with every handover kept, and a `support.thread` presence room shows who else has a thread open, and who is replying, before you answer it twice. Your signed-in users reach the same inbox without leaving the app: POST /support/feedback opens a thread behind requireAuth(), into the same table, the same classifier, and the same taxonomy — no second inbox, no second console. That channel is where the mail path's hardest problem does not exist, because there is no From: header to spoof: the session is the identity, so the thread records whether its account link was proven by a session or merely matched against an address, and a console can tell the two apart. Replies go out through @pithy-sh/email carrying your domain, your DKIM, and correct threading headers — which only the Worker can set — whichever channel the question arrived on. The admin surface is control-plane and default-denied, except to your own staff through `support({ staff })`, who may assign a thread and join its presence room from a session; the three in-app feedback routes answer to a user's session and to no scope at all. **Cloudflare Email Routing takes over a zone's MX**, so use a subdomain (support@help.yourdomain.com) and never your apex, or you will move your real mail off your existing provider.",
   "scaffold": [
     "Pick the address this inbox will answer on, and put it in `inboundAddresses`. **Use a subdomain, never your apex.** Enabling Email Routing on a zone points its MX at Cloudflare, so `support@yourdomain.com` would move all of your real inbound mail off your current provider. `support@help.yourdomain.com` costs you a subdomain zone and nothing else. Until this is set the inbox is inert and ignores every message.",
     "Ensure the secrets capability is provisioned (`pithy add secrets` then `pithy secrets provision`) — the R2 credentials attachment URLs are signed with are stored and read through @pithy-sh/secrets.",
     "Run `pithy support provision --routing-zone <zone-id> --inbound-address <addr> --app-worker <name>`. It creates the `SUPPORT_BUCKET` R2 bucket, deploys the prebuilt classification worker for each environment, and creates the Email Routing rule that delivers mail to your app worker. Idempotent; re-run it freely.",
     "Add the `DB` (D1) binding to each wrangler.jsonc env. `SUPPORT_BUCKET` (R2) is written for you when your config keeps attachments, the raw MIME copy, or in-app uploads, and left out entirely when it keeps none of them. Add the `SUPPORT_CLASSIFY` Workflow binding your app dispatches to after storing a message — `pithy support provision` writes it.",
-    "Add the controlplane capability (`pithy add controlplane`) and run `pithy dashboard connect`. Every support route is control-plane only and default-denied: without a registered connection the whole admin surface answers 403, which is the correct posture for an inbox holding other people's private correspondence. Grant the five scopes deliberately — `support:threads:reply` sends mail to real people under your domain and is not the same permission as reading.",
+    "Add the controlplane capability (`pithy add controlplane`) and run `pithy dashboard connect`. Every management route is control-plane and default-denied, except to your own staff through `support({ staff })`: without a registered connection the admin surface answers 403, which is the correct posture for an inbox holding other people's private correspondence. Grant the six scopes deliberately — `support:threads:reply` sends mail to real people under your domain and is not the same permission as reading, and `support:threads:assign` decides who answers whom.",
     "Add the email capability (`pithy add email`) if you want to answer from the dashboard. Without it the inbox still receives, threads, and classifies; the reply route returns `support/reply_failed` naming what is missing.",
     "Add auth and payments if you have them. Neither is required, and both are reached by guarded dynamic import — with them installed a thread arrives already knowing who the sender is, what they bought, and whether their last renewal failed. **Auth is what makes the in-app channel work at all**: without it `c.var.auth` is null and every `/support/feedback` route denies, which is the correct posture rather than a bug.",
     "Point your app's feedback form at `POST /support/feedback` and pass the screen, build, and environment as `context`. That set is closed — an undeclared key is refused rather than stored, so this cannot quietly become a telemetry pipe. Review `submission.attachments` before you ship it: the size, count, and content-type allowlist are stated for a direct upload rather than inherited from the mail path, which has no type restriction at all. Set `submission: { enabled: false }` and the routes are not mounted.",
     "Add your own categories with `defineSupportCategories({ ... })` and your own canned replies with `defineSupportReplies({ ... })`. A category's description is prompt input, read by the model verbatim; a canned reply is a starting point a human picks and edits, never something sent automatically.",
     "If your feedback screen offers a chooser, send its answer as `declaredCategory`. It lands in its own column beside `category` and is never overwritten by the classifier — one is a claim by the person writing, the other a judgement about them, and an operator triaging an inbox needs to tell them apart. `GET /support/threads` filters on either. A key outside your taxonomy is refused rather than stored, and a category sent with a `threadId` is refused too: a chooser belongs on the form that opens a request.",
     "`POST /support/feedback` is gated on a session and same-origin and never on a role — a general intake that is role-gated is not one. If your own account model makes some submissions act-on-behalf-of, put that check in your `app` capability's `middleware` over your own `basePath`: every capability's middleware mounts before any capability's routes, so yours runs after auth has resolved the session and before this capability's `requireAuth()`.",
-    "Leave `search.fts` off unless your inbox has outgrown a `LIKE` scan. Turning it on builds an FTS5 index, and an FTS5 virtual table anywhere in a D1 database makes `wrangler d1 export` refuse to dump the **whole** database — your other tables included."
+    "If your own signed-in users work the inbox, name two powers in `support({ staff: { readPower, assignPower } })` and give them to a role in your organization catalog's `unassignable` list that `organization({ ownership })` does not confer, so only an operator can confer them — anybody may found an organization and take its ownership role, so `support()` refuses a staff power there. `readPower` lets a staff member join a thread's presence room; `assignPower` lets them assign it at `POST /support/staff/threads/:id/assign`. Without `staff`, both answer to management clients only.",
+    "Search the inbox at `GET /support/threads/search` — keyword by default, ranked; the inbox list takes no `q`. Turn on `search: { semantic: true }` to find a paraphrase as well as an exact word: it embeds every inbound message on your own Workers AI binding, a second inference per message on top of classification, so it is off until you choose it. Then run `pithy support provision`, which creates the Vectorize index, binds it, and backfills it once; `pithy vector reprocess --index support-messages` re-embeds after a model change.",
+    "Run `pithy support provision` after adding support or upgrading it: `search.fts` is on by default, and the FTS5 index and its triggers are provisioned rather than migrated. Until then search falls back to a `LIKE` scan and `pithy doctor` names the environment. Back the database up with `pithy backup`, which skips the index, and restore it with `pithy restore`, which rebuilds it — a plain `wrangler d1 export` fails on any database holding an FTS5 table."
   ],
   "configOptions": [
     {

package/src/audit/actions.ts

@@ -30,6 +30,15 @@ export const SupportAuditActions = {
   threadArchived: "support/thread_archived",
   /** A thread was taken back out of the archive. Recorded separately, because undoing is its own decision. */
   threadUnarchived: "support/thread_unarchived",
+  /**
+   * A thread was given to somebody, or handed from one person to another (#816). Audited because who has
+   * a customer's conversation decides who answers them, and the thread keeps only the current answer.
+   * Metadata: the previous assignee, the new one, and the assigner's note — staff words, never mail.
+   * Reassigning the current assignee changes nothing and emits nothing.
+   */
+  threadAssigned: "support/thread_assigned",
+  /** A thread's assignee was cleared. Its own action, because giving a conversation up is its own decision. */
+  threadUnassigned: "support/thread_unassigned",
   /**
    * A reply went out. Audited because it leaves under the adopter's domain and their DKIM: to the
    * recipient it is indistinguishable from the founder writing it, so who actually sent it is a

package/src/capability.ts

@@ -26,10 +26,19 @@ import { supportAdminRoutes } from "./http/scopes";
 import { createSupportEmailHandler } from "./inbound/handler";
 import { senderPeers } from "./link/peers";
 import type { SenderPeers } from "./link/sender";
-import { support_0001_threads } from "./migrations/0001_threads";
+import { SUPPORT_MIGRATIONS } from "./migrations/set";
+import { supportPresence } from "./presence/room";
+import { supportUserPurge } from "./purge/contribution";
 import { resolveReplies, type SupportReplySnippets } from "./reply/snippets";
 import { inapplicableAttachmentSecrets, SUPPORT_BUCKET_BINDING, supportSecretsRegistry } from "./secret/registry";
 import { supportExampleSeed } from "./seeds/example";
+import {
+  SUPPORT_AI_BINDING,
+  SUPPORT_MESSAGES_INDEX,
+  SUPPORT_VECTORIZE_BINDING,
+  supportMessageIndex,
+} from "./semantic/messageIndex";
+import { assertStaffComposition } from "./staff/staff";
 import { PACKAGE_NAME, PACKAGE_VERSION } from "./version.generated";
 import { supportWorkflows } from "./workflows/specs";
 
@@ -182,7 +191,8 @@ export interface SupportCapability
  * The support capability — an inbound support inbox in the adopter's own D1, classified on their own
  * Workers AI binding.
  *
- * It contributes five tables (and optionally a full-text index) to the app `DB`, an `email()` handler
+ * It contributes its tables (and optionally a full-text index, and a semantic message index in Vectorize) to the
+ * app `DB`, an `email()` handler
  * that claims the configured addresses out of the Worker's single inbound entry, the classification
  * Workflow that handler dispatches to, and a control-plane admin surface for a dashboard to read and
  * act on.
@@ -213,13 +223,13 @@ export function support(options: SupportOptions = {}): SupportCapability {
     emit: noopEmit,
   };
 
-  // One migration, unconditionally. The full-text index is **not** here: it is derived from the
+  // The whole chain, unconditionally. The full-text index is **not** in it: it is derived from the
   // messages table and rebuildable at any time, so it is a provisioned resource that
   // `pithy support provision` creates and drops (see `store/searchIndex.ts`), not schema whose loss
   // loses data. Keeping it out of the ledger is what makes `search.fts` safe to toggle in either
   // direction — a config flag must never be able to corrupt a migration set shared with every other
   // capability in the database.
-  const migrations: Record<string, Migration> = { "0001_threads": support_0001_threads };
+  const migrations: Record<string, Migration> = SUPPORT_MIGRATIONS;
 
   const requiredBindings: BindingSpecInput[] = [
     // The app database every support table lives in.
@@ -239,6 +249,17 @@ export function support(options: SupportOptions = {}): SupportCapability {
     // The classification Workflow the inbound handler dispatches to, derived from the spec rather
     // than listed again — one declaration, so a binding rename cannot leave the two disagreeing.
     ...workflowBindings(supportWorkflows),
+    // The semantic message index and the model that embeds a query, **only when `search.semantic` is
+    // on**. The index's `index_name` is a provisioning output, so `pithy support provision` writes the entry
+    // once the index exists; until then it is absent and the search route skips the semantic backend, naming
+    // it, which is why the binding is optional. Neither has a local emulation, so both reach the real resource
+    // under `wrangler dev`.
+    ...(supportMessageIndex(resolved.search)
+      ? [
+          { type: "vectorize" as const, name: SUPPORT_VECTORIZE_BINDING, optional: true, remote: true },
+          { type: "ai" as const, name: SUPPORT_AI_BINDING, remote: true },
+        ]
+      : []),
   ];
 
   const capability = defineCapability({
@@ -276,7 +297,12 @@ export function support(options: SupportOptions = {}): SupportCapability {
      * able to answer is a coherent and useful thing, so a missing email capability degrades one
      * route instead of refusing to boot.
      */
+    // Support's staff powers, when the adopter names them, so tenancy refuses a catalog that places them on
+    // no role. Absent until named: a capability never reserves a power in a catalog that is the adopter's.
+    ...(resolved.staff ? { powers: [resolved.staff.readPower, resolved.staff.assignPower] } : {}),
     compose: ({ capabilities }) => {
+      // A staff block no request could be served by safely is refused here, at boot. See `staff/staff.ts`.
+      assertStaffComposition(resolved.staff, capabilities);
       const email = capabilities.find(isEmailCapability);
       wiring.enqueueEmail = email?.enqueue;
       // Auth and payments, found rather than imported (#645), and refused here when this Worker's config needs
@@ -288,13 +314,26 @@ export function support(options: SupportOptions = {}): SupportCapability {
     // for why the list is as short as it is.
     client: (): SupportClientProjection => clientProjection(resolved, mountPath),
     adminRoutes: supportAdminRoutes(mountPath),
+    // The semantic message index, so `pithy vector reprocess` re-embeds it beside every `vector()` index.
+    // Declared only when it exists to re-embed.
+    ...(supportMessageIndex(resolved.search)
+      ? { vectorIndexes: [{ name: SUPPORT_MESSAGES_INDEX, reprocessJob: "reprocess" }] }
+      : {}),
+    // Who else has a thread open (#816): one `support.thread` room per thread, on core's presence seam.
+    // Declaring it is the whole of the wiring — core adds the room's binding, socket and ticket routes.
+    presence: supportPresence(mountPath, wiring),
     routes: registerSupportRoutes({
       basePath: mountPath,
       submission: resolved.submission.enabled,
       resolveDeps: makeResolveDeps(wiring),
+      staff: resolved.staff,
     }),
     email: createSupportEmailHandler(wiring),
     seeds: [supportExampleSeed],
+    // A person's threads — linked to their account, or sent from their address and linked to no other — with every
+    // message, attachment and raw mail in them: exported on an access request and erased by their purge, as its own
+    // step (#814).
+    purge: [supportUserPurge("DB", { semantic: supportMessageIndex(resolved.search) !== undefined })],
   });
 
   return Object.assign(capability, {

package/src/config/config.ts

@@ -324,25 +324,121 @@ export const SupportReplyConfig = z
   );
 export type SupportReplyConfig = z.output<typeof SupportReplyConfig>;
 
+/**
+ * The default embedding model for semantic search — the kit's own default (`DEFAULT_EMBEDDING_MODEL` in
+ * `@pithy-sh/cloudflare/src/ai/aiManager.ts`), restated rather than imported because a Worker cannot reach
+ * the REST client package and should not.
+ *
+ * **Multilingual, and that is why.** An inbox takes mail in whatever language the customer writes, and an
+ * English-only model would embed a Spanish complaint into the wrong neighborhood with no error.
+ */
+export const DEFAULT_EMBEDDING_MODEL = "@cf/baai/bge-m3";
+
+/**
+ * How many components `bge-m3` produces. It is not a Vectorize preset, so the index states its own shape;
+ * a model override that produces another width states its `dimensions` beside it.
+ */
+export const DEFAULT_EMBEDDING_DIMENSIONS = 1024;
+
+/** The `{ model }` form of `search.semantic`: semantic search on, with a model of your choosing. */
+export const SupportSemanticConfig = z
+  .object({
+    model: z
+      .string()
+      .min(1)
+      .default(DEFAULT_EMBEDDING_MODEL)
+      .describe(
+        "The Workers AI embedding model the message index is built and queried with. Pinned: change it and `pithy vector reprocess --index support-messages` re-embeds what the old one wrote.",
+      ),
+    dimensions: z
+      .number()
+      .int()
+      .min(1)
+      .max(1536)
+      .default(DEFAULT_EMBEDDING_DIMENSIONS)
+      .describe(
+        "How many components the model produces — 1024 for `bge-m3`, 768 for `bge-base-en-v1.5`. Fixed when the index is created, so a model of another width needs the index dropped and recreated.",
+      ),
+  })
+  .describe("Semantic search with a chosen embedding model.");
+export type SupportSemanticConfig = z.output<typeof SupportSemanticConfig>;
+
 /**
  * How text search is answered.
  *
- * The one setting here has a cost an adopter must opt into knowingly, which is why it is a setting
- * at all rather than a decision this package made for them.
+ * FTS5 by default, with the `LIKE` scan kept for a project that wants no virtual table at all. Semantic
+ * search is off by default because it costs a second inference per inbound message.
  */
 export const SupportSearchConfig = z
   .object({
+    semantic: z
+      .union([z.boolean(), SupportSemanticConfig])
+      .default(false)
+      .describe(
+        "Search by meaning as well as by words: `true` for the default model (`@cf/baai/bge-m3`), or `{ model }` for your own. **Off by default, and the reason is cost.** Every inbound message is embedded once, on your own Workers AI binding, in the classification Workflow — a second inference per message on top of classification, which roughly doubles this capability's per-message AI cost. The volume guard bounds messages, not spend. On, `pithy support provision` creates a Vectorize index and backfills it once; off, it drops the index. Vectors carry message ids and nothing else.",
+      ),
     fts: z
       .boolean()
-      .default(false)
+      .default(true)
       .describe(
-        "Build a SQLite FTS5 index over message subjects and bodies. **Off by default, and the reason is not performance.** `wrangler d1 export` refuses to dump any database containing an FTS5 virtual table — it fails outright rather than skipping the table — and the check runs server-side across the whole database before `--table` filtering, so turning this on takes your **entire app database's** export with it. A failed attempt has also been reported to leave the database inaccessible until it clears. If you do not use `wrangler d1 export`, none of that reaches you and FTS5 is the better search. Safe to toggle either way: the index is derived rather than migrated, so `pithy support provision` creates or drops it to match — and until you re-provision, search falls back to the `LIKE` scan rather than failing.",
+        "Build a SQLite FTS5 index over message subjects and bodies — a ranked word search instead of an unindexed `LIKE` scan. **On by default.** A plain `wrangler d1 export` of a database holding an FTS5 table fails outright, so `pithy backup` leaves the index and its triggers out and `pithy restore` rebuilds them from `pithy_support_messages`; the bare `wrangler` route has to skip it by hand. The index is derived rather than migrated, so `pithy support provision` creates or drops it to match this flag, and until a project re-provisions, search falls back to the `LIKE` scan and `pithy doctor` names the environment.",
       ),
   })
-  .describe("Text search settings — the `LIKE` scan by default, FTS5 as a deliberate opt-in.");
+  .describe(
+    "Search settings — FTS5 by default, the `LIKE` scan when it is off or not yet provisioned, and semantic search an opt-in priced in resources you own.",
+  );
 export type SupportSearchConfig = z.output<typeof SupportSearchConfig>;
 
+/**
+ * The semantic model and width this configuration asks for, or `undefined` when semantic search is off.
+ *
+ * The one reading of the three-shaped flag — `false`, `true`, `{ model }` — so the capability's bindings,
+ * the search route, the classification Workflow and provisioning cannot each decide what `true` means.
+ */
+export function supportSemantic(search: SupportSearchConfig): SupportSemanticConfig | undefined {
+  if (search.semantic === false) return undefined;
+  if (search.semantic === true) return { model: DEFAULT_EMBEDDING_MODEL, dimensions: DEFAULT_EMBEDDING_DIMENSIONS };
+  return search.semantic;
+}
+
 /** The full support configuration. */
+/**
+ * **Who of the app's own signed-in users works the inbox (#816).** Off until named.
+ *
+ * The inbox holds every customer's correspondence, so a signed-in user reaches it only through a power the
+ * adopter names in their own role catalog, held in the organization the request acts for — the same seam
+ * `media:manage` and `storage:manage` ask, and the same rule `artifacts({ managePower })` follows: a
+ * capability never reserves a power name in a catalog that is the adopter's.
+ *
+ * **Both powers must sit only on roles no organization can hand itself** — listed in
+ * `defineRoles({ unassignable })`, and not the role `organization({ ownership })` confers — and `support()`
+ * refuses the composition otherwise. A role is the catalog's, not one organization's, and an organization's
+ * own administrator may give any assignable role to their own members — so a support power on an assignable
+ * role would let any customer's administrator make themselves staff and read every other customer's mail.
+ * The ownership role is unassignable and still self-served: anybody may found an organization, nominate
+ * themselves its owner, and accept. On any other unassignable role it is conferred by an operator alone,
+ * through the control plane.
+ */
+export const SupportStaffConfig = z
+  .object({
+    readPower: z
+      .string()
+      .min(1)
+      .describe(
+        "The power that lets a signed-in user see who else has a thread open — what the `support.thread` presence room's session ticket asks. Your own name, declared in your role catalog on unassignable roles only, and not on the role ownership transfer confers, e.g. `support:read`.",
+      ),
+    assignPower: z
+      .string()
+      .min(1)
+      .describe(
+        "The power that lets a signed-in user assign a thread, to themselves or to somebody else, at `POST {basePath}/staff/threads/:id/assign`. Your own name, declared in your role catalog on unassignable roles only, and not on the role ownership transfer confers, e.g. `support:assign`.",
+      ),
+  })
+  .describe(
+    "Who of your app's own signed-in users works the inbox, by the organization powers their role holds. Requires `organization`, and both powers on unassignable roles other than the one ownership transfer confers. Absent, no signed-in user can assign a thread or join a thread's presence room — management clients still can, through the control plane.",
+  );
+export type SupportStaffConfig = z.output<typeof SupportStaffConfig>;
+
 export const SupportConfig = z
   .object({
     inboundAddresses: z
@@ -373,6 +469,9 @@ export const SupportConfig = z
     submission: SupportSubmissionConfig.prefault({}).describe("The in-app submission channel."),
     reply: SupportReplyConfig.prefault({}).describe("Reply settings."),
     search: SupportSearchConfig.prefault({}).describe("How text search is answered."),
+    staff: SupportStaffConfig.optional().describe(
+      "Who of your app's signed-in users works the inbox, by organization power. Absent, the staff session routes refuse everyone.",
+    ),
   })
   .describe(
     "Configuration for the support capability — which addresses it claims, and how it classifies and bounds them.",