@pithy-sh/support 0.1.2 → 0.1.3

package/dist/capability.js

@@ -0,0 +1,187 @@
+import { resolveReplies } from "./reply/snippets.js";
+import { SupportConfig, supportNeedsBucket } from "./config/config.js";
+import { resolveCategories } from "./data/categories.js";
+import { supportTables } from "./data/tables.js";
+import { supportSecretsRegistry } from "./secret/registry.js";
+import { supportWorkflows } from "./workflows/specs.js";
+import { makeResolveDeps } from "./http/resolve.js";
+import { supportAdminRoutes } from "./http/scopes.js";
+import { registerSupportRoutes } from "./http/routes.js";
+import { createSupportEmailHandler } from "./inbound/handler.js";
+import { support_0001_threads } from "./migrations/0001_threads.js";
+import { supportExampleSeed } from "./seeds/example.js";
+import { PACKAGE_VERSION } from "./version.generated.js";
+import { noopEmit } from "@pithy-sh/core/src/audit/recorder";
+import { defineCapability } from "@pithy-sh/core/src/capability/capability";
+import { workflowBindings } from "@pithy-sh/core/src/workflow/bindings";
+import { isEmailCapability } from "@pithy-sh/email/src/capability";
+//#region src/capability.ts
+/**
+* Sort order of the support migrations within the app database, relative to other capabilities.
+* Unique per database; the registry composes keys like `1200_support_0001_threads`.
+*
+* Taken from `NEXT_FREE_ORDER` in `packages/cli/src/migrations/orders.test.ts` at implementation
+* time, as the procedure in that file requires — never picked by grepping, which is how two pairs of
+* capabilities once collided in a range that was 99% empty. Stable forever: renumbering would rename
+* the composed keys, and Kysely would then read applied migrations as unapplied and re-run them.
+*/
+const SUPPORT_MIGRATION_ORDER = 1200;
+/**
+* What a browser may know about this project's support — the `virtual:pithy/support` module.
+*
+* **One route on this capability is called by a browser**, and that is the whole reason this exists:
+* `POST {basePath}/feedback`, with the two reads beside it. Everything else answers to a control-plane
+* credential a management client holds, and a management client reads the manifest. So the list is
+* `basePath` and the bounds the compose form must hold somebody to before it lets them press Send —
+* a form that stops at 200 characters because the handler refuses at 200 characters is a better form
+* than one that finds out afterwards.
+*
+* **`{ enabled: false }` when the submission channel is off**, and that is not the same statement as
+* "support is not composed" only in a sentence nobody writes. `registerSupportRoutes` does not mount
+* the feedback routes when `submission.enabled` is false — they answer 404, not 403 — so a browser
+* then has nothing on this capability to call and no use for a path. A screen branches on `enabled`
+* rather than guarding, exactly as it does for a payments catalog with nothing in it.
+*
+* **What deliberately does not cross, and why each one was considered.**
+* - **The taxonomy.** A category's value is the instruction a model reads and it lands in the prompt
+*   verbatim — prompt input written for a classifier, not copy for a chooser. An adopter's UI wants
+*   its own words either way, and the descriptions are the closest thing here to authored internals.
+* - **`inboundAddresses` and `reply.replyToAddress`.** The inbox's own mail addresses. A browser never
+*   writes to them, and publishing an address into every bundle is a favor to nobody but a spammer.
+* - **`reply.snippets`.** Canned copy an operator picks and edits in a dashboard. Staff-side, and the
+*   dashboard reads it through the control-plane route that already serves it.
+* - **`submission.maxPerAccountPerHour`.** A rate a client cannot pre-enforce honestly — the count
+*   lives in D1 and the server's refusal is the only truth about it — so projecting it would publish
+*   an abuse budget in exchange for a number no form can act on.
+* - **`ai`, `guard`, `attachments`, `search`.** The model and its prompt budget, the mail path's size
+*   and rate bounds, what happens to mail attachments, and how search is indexed. Each describes the
+*   deployment or a surface a browser never touches. The mail path's `attachments` block in
+*   particular is *not* the submission's: `config.ts` says at length why the two are stated
+*   separately, and inheriting one for the other here would undo that in the one place it reaches a
+*   client.
+*
+* There is no secret in reach of this closure to begin with — the R2 credential bundle lives in the
+* secrets store behind `supportSecretsRegistry` and is never in config — so what discipline covers is
+* the list above. `capability.test.ts` locks the key set by hand and sweeps the serialized result.
+*
+* `null` for attachments that are off, never `undefined`: the projection is inlined into a bundle with
+* `JSON.stringify`, which drops an undefined value and leaves the screen reading a key that is simply
+* absent. Null is also what makes "render no file picker" one check rather than three absences.
+*
+* The return type is {@link SupportClientProjection} — **declared, not inferred**. `ClientProjection` is
+* `{ enabled: boolean }` plus a JSON catchall, which accepts anything this function could return. The
+* declared type is what makes a dropped field a compile error here rather than a browser's problem, and
+* what stops the list above widening by accident when `SupportConfig` grows.
+*/
+function clientProjection(config, basePath) {
+	const submission = config.submission;
+	if (!submission.enabled) return { enabled: false };
+	const attachments = submission.attachments;
+	return {
+		enabled: true,
+		basePath,
+		submission: {
+			maxSubjectChars: submission.maxSubjectChars,
+			maxBodyChars: submission.maxBodyChars,
+			attachments: attachments.enabled ? {
+				maxCount: attachments.maxCount,
+				maxBytes: attachments.maxBytes,
+				allowedContentTypes: [...attachments.allowedContentTypes]
+			} : null
+		}
+	};
+}
+/**
+* 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
+* 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.
+*
+* **Nothing here is gated by tier.** Every route is reachable with a control-plane credential the
+* adopter issued, whatever anyone pays; a hosted dashboard gates its own UI and nothing else.
+* Crippling MIT code would be both wrong and futile.
+*
+* Attachments presign through `@pithy-sh/storage`'s `ObjectStore` against `SUPPORT_BUCKET` under a
+* credential name support declares, so `secrets` must be composed. The admin routes need the
+* `control-plane` seam; without it every one denies, which is the correct failure for an inbox
+* holding other people's correspondence. `@pithy-sh/auth` and `@pithy-sh/payments` are reached by
+* guarded dynamic import for the sender link, so both stay genuinely optional.
+*/
+function support(options = {}) {
+	const { basePath, ...configInput } = options;
+	const resolved = SupportConfig.parse(configInput);
+	const categories = resolveCategories(resolved.categories);
+	const snippets = resolveReplies(resolved.reply.snippets);
+	const mountPath = basePath ?? "/support";
+	const wiring = {
+		config: resolved,
+		categories,
+		snippets,
+		enqueueEmail: void 0,
+		emit: noopEmit
+	};
+	const migrations = { "0001_threads": support_0001_threads };
+	const requiredBindings = [
+		{
+			type: "d1",
+			name: "DB"
+		},
+		...supportNeedsBucket(resolved) ? [{
+			type: "r2",
+			name: "SUPPORT_BUCKET",
+			optional: true
+		}] : [],
+		...workflowBindings(supportWorkflows)
+	];
+	const capability = defineCapability({
+		name: "support",
+		version: PACKAGE_VERSION,
+		dependsOn: ["secrets"],
+		secretRegistry: supportSecretsRegistry,
+		workflows: supportWorkflows,
+		requiredBindings,
+		ciPermissions: ["email:routing"],
+		databases: { app: {
+			binding: "DB",
+			tables: supportTables,
+			migrationOrder: SUPPORT_MIGRATION_ORDER,
+			migrations
+		} },
+		/**
+		* Bind the optional email seam once, at startup.
+		*
+		* Deliberately not a hard `dependsOn`. Auth *requires* email — a magic link that cannot be sent
+		* is a broken sign-in — but a support inbox that receives, threads, and classifies without being
+		* able to answer is a coherent and useful thing, so a missing email capability degrades one
+		* route instead of refusing to boot.
+		*/
+		compose: ({ capabilities }) => {
+			const email = capabilities.find(isEmailCapability);
+			wiring.enqueueEmail = email?.enqueue;
+		},
+		client: () => clientProjection(resolved, mountPath),
+		adminRoutes: supportAdminRoutes(mountPath),
+		routes: registerSupportRoutes({
+			basePath: mountPath,
+			submission: resolved.submission.enabled,
+			resolveDeps: makeResolveDeps(wiring)
+		}),
+		email: createSupportEmailHandler(wiring),
+		seeds: [supportExampleSeed]
+	});
+	return Object.assign(capability, {
+		supportConfig: resolved,
+		categories,
+		snippets,
+		basePath: mountPath
+	});
+}
+/** Whether a capability is the support capability — carries its resolved config and effective taxonomy. */
+function isSupportCapability(capability) {
+	return capability.name === "support" && "supportConfig" in capability;
+}
+//#endregion
+export { SUPPORT_MIGRATION_ORDER, isSupportCapability, support };

package/dist/client/projection.d.ts

@@ -0,0 +1,56 @@
+/**
+ * What a browser may know about this project's support inbox — the shape of `virtual:pithy/support`.
+ *
+ * **This declaration is the contract, and the projection is checked against it.** It is written here
+ * rather than inferred from the closure that builds it, and that is the whole point: an inferred type
+ * follows whatever the producer last happened to say, so a projection that dropped `maxBodyChars`, or
+ * that started passing the mail path's attachment bounds through because `SupportConfig` moved a field,
+ * would take the type with it and nothing would go red. Declared, the arrow is the thing that has to
+ * change — and every widening of what a browser sees is a decision made here, on purpose.
+ *
+ * The list is short on purpose and `clientProjection`'s own comment says at length what stays behind:
+ * the taxonomy, the inbound addresses, the reply snippets, the per-account rate, and the whole `ai`,
+ * `guard`, mail-`attachments` and `search` blocks.
+ *
+ * **This is the only statement of the shape.** `@pithy-sh/ui-react`'s `templates/client-env.d.ts` — the
+ * ambient declaration `pithy ui add react` copies into an adopter's Worker — is generated from this type
+ * by `@pithy-sh/vite`'s `clientEnvDeclaration.ts` (#398). The unions and the per-field doc comments below
+ * are emitted verbatim, so what is written here is what a screen author reads.
+ */
+export type SupportClientProjection = {
+    /**
+     * Support is not composed, or is not serving the in-app submission routes — the only ones a
+     * browser calls. A screen branches rather than rendering a compose form nothing will accept.
+     */
+    enabled: false;
+} | {
+    /** Support is composed AND serving the in-app submission routes. */
+    enabled: true;
+    /** Where the support routes mount, e.g. `/support`. `POST {basePath}/feedback` writes in. */
+    basePath: string;
+    /**
+     * What one submission may carry. Hold a compose form to these so the handler does not have to
+     * refuse after somebody pressed Send. The taxonomy is not here: a category's text is the
+     * instruction a classifier reads, not copy for a chooser.
+     */
+    submission: {
+        /** The longest subject accepted. It becomes the thread's name in the inbox. */
+        maxSubjectChars: number;
+        /** The longest report body accepted. */
+        maxBodyChars: number;
+        /**
+         * What an upload control may offer, or null when attachments are off and it renders none.
+         * Null rather than absent: the projection is inlined with `JSON.stringify`, which drops an
+         * undefined value and leaves a screen reading a key that is simply gone.
+         */
+        attachments: {
+            /** How many files one submission may carry. */
+            maxCount: number;
+            /** The largest single file, measured on the decoded bytes. */
+            maxBytes: number;
+            /** The exact MIME types accepted — an allowlist, and the `accept` a file input wants. */
+            allowedContentTypes: string[];
+        } | null;
+    };
+};
+//# sourceMappingURL=projection.d.ts.map

package/dist/client/projection.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"projection.d.ts","sourceRoot":"","sources":["../../src/client/projection.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,MAAM,uBAAuB,GAC/B;IACE;;;OAGG;IACH,OAAO,EAAE,KAAK,CAAC;CAChB,GACD;IACE,oEAAoE;IACpE,OAAO,EAAE,IAAI,CAAC;IACd,6FAA6F;IAC7F,QAAQ,EAAE,MAAM,CAAC;IACjB;;;;OAIG;IACH,UAAU,EAAE;QACV,+EAA+E;QAC/E,eAAe,EAAE,MAAM,CAAC;QACxB,wCAAwC;QACxC,YAAY,EAAE,MAAM,CAAC;QACrB;;;;WAIG;QACH,WAAW,EAAE;YACX,+CAA+C;YAC/C,QAAQ,EAAE,MAAM,CAAC;YACjB,8DAA8D;YAC9D,QAAQ,EAAE,MAAM,CAAC;YACjB,yFAAyF;YACzF,mBAAmB,EAAE,MAAM,EAAE,CAAC;SAC/B,GAAG,IAAI,CAAC;KACV,CAAC;CACH,CAAC"}

package/dist/config/config.d.ts

@@ -0,0 +1,215 @@
+import { z } from "zod";
+/**
+ * The support capability's configuration — the thin, user-owned surface in `pithy.config.ts`.
+ *
+ * The one field with no sensible default is `inboundAddresses`, and the reason is worth stating
+ * where an adopter will read it: **Cloudflare Email Routing takes over a zone's MX.** An address on
+ * the apex would move the adopter's real mail off their existing provider, so the address is theirs
+ * to choose deliberately — almost always on a subdomain (`support@help.theirdomain.com`) — and this
+ * capability will not guess one. Until it is set the inbox is inert: every message is ignored, and
+ * the handler says so once in the log rather than quietly storing mail from an address nobody
+ * configured.
+ */
+/**
+ * The default Workers AI model for classification.
+ *
+ * An instruct model rather than a classifier: the taxonomy is federated, so the valid label set is
+ * not known until an adopter composes the capability, and a fine-tuned classifier cannot be given new
+ * classes in a config file. Small on purpose — this runs once per inbound message on the adopter's
+ * own bill, and the judgment is "which of these eight sentences fits", not a reasoning task.
+ */
+export declare const DEFAULT_CLASSIFY_MODEL = "@cf/meta/llama-3.1-8b-instruct";
+/** How the inbound message is classified, and by what. */
+export declare const SupportAiConfig: z.ZodObject<{
+    enabled: z.ZodDefault<z.ZodBoolean>;
+    model: z.ZodDefault<z.ZodString>;
+    maxChars: z.ZodDefault<z.ZodNumber>;
+    temperature: z.ZodDefault<z.ZodNumber>;
+}, z.core.$strip>;
+export type SupportAiConfig = z.output<typeof SupportAiConfig>;
+/** What happens to files that arrive attached to a message. */
+export declare const SupportAttachmentsConfig: z.ZodObject<{
+    enabled: z.ZodDefault<z.ZodBoolean>;
+    maxBytes: z.ZodDefault<z.ZodNumber>;
+    maxCount: z.ZodDefault<z.ZodNumber>;
+    retainRaw: z.ZodDefault<z.ZodBoolean>;
+}, z.core.$strip>;
+export type SupportAttachmentsConfig = z.output<typeof SupportAttachmentsConfig>;
+/**
+ * The spam and volume guard.
+ *
+ * A public address is a public write endpoint into the adopter's D1, and that is the honest way to
+ * think about it. These bounds are what stop a mail flood from being a storage bill.
+ */
+export declare const SupportGuardConfig: z.ZodObject<{
+    maxRawBytes: z.ZodDefault<z.ZodNumber>;
+    maxPerSenderPerHour: z.ZodDefault<z.ZodNumber>;
+    maxPerHour: z.ZodDefault<z.ZodNumber>;
+    trustAuthenticationResults: z.ZodDefault<z.ZodBoolean>;
+    authservId: z.ZodOptional<z.ZodString>;
+    archiveSpam: z.ZodDefault<z.ZodBoolean>;
+}, z.core.$strip>;
+export type SupportGuardConfig = z.output<typeof SupportGuardConfig>;
+/**
+ * What a signed-in user may attach to an in-app submission.
+ *
+ * **Stated here rather than inherited from `attachments`, and that is the point.** The mail path's
+ * bounds were written for parts of a MIME message somebody sent to a public address: they cap size and
+ * count, and they say nothing at all about type, because there is no useful type restriction on mail —
+ * refusing a `.docx` a customer attached to a bug report would lose the report. A direct upload from a
+ * browser is a different surface with a different answer: the client is authenticated but untrusted,
+ * the useful payload is a screenshot, and an allowlist is both possible and worth having. Inheriting
+ * the email numbers would have meant a 10 MB any-type upload endpoint arriving as a side effect of a
+ * setting an adopter tuned for their inbox.
+ *
+ * Bytes are stored exactly as the mail path stores them — server-derived opaque key,
+ * `application/octet-stream` on the object whatever was declared — so nothing here re-opens the
+ * stored-XSS question `attachment/store.ts` already closed.
+ */
+/**
+ * The hard ceiling on how many attachments one submission may declare, whatever
+ * `submission.attachments.maxCount` is set to.
+ *
+ * On the schema as well as in the handler because the two refuse at different moments and the earlier
+ * one is free: the validator rejects a thousand-element array before a handler runs, without reading
+ * the resolved config. The configured bound is what an adopter tunes; this is what is true regardless.
+ */
+export declare const MAX_SUBMISSION_ATTACHMENTS = 10;
+export declare const SupportSubmissionAttachmentsConfig: z.ZodObject<{
+    enabled: z.ZodDefault<z.ZodBoolean>;
+    maxBytes: z.ZodDefault<z.ZodNumber>;
+    maxCount: z.ZodDefault<z.ZodNumber>;
+    allowedContentTypes: z.ZodDefault<z.ZodArray<z.ZodString>>;
+}, z.core.$strip>;
+export type SupportSubmissionAttachmentsConfig = z.output<typeof SupportSubmissionAttachmentsConfig>;
+/**
+ * The ceilings a configured submission bound may not exceed — the route's own schema is written to
+ * these, so a payload beyond one is refused by the validator before a handler runs.
+ *
+ * Two layers, and both earn their place. The **config** bound is the adopter's number and produces the
+ * message their user reads; the **schema** ceiling is what stops a megabyte of text reaching a handler
+ * at all, and it cannot be config-derived because a request schema is built once at module load while
+ * config is resolved per project. Bounding the config field by the same constant is what keeps them
+ * from disagreeing: a setting above the ceiling would be a limit the route silently refused to honor.
+ */
+export declare const MAX_SUBMISSION_SUBJECT_CHARS = 500;
+/** The hard ceiling on a submission body, whatever `submission.maxBodyChars` is set to. */
+export declare const MAX_SUBMISSION_BODY_CHARS = 100000;
+/**
+ * The in-app submission channel: a signed-in user of the adopter's own app opening a support thread
+ * without leaving it.
+ *
+ * **The hardest problem in the mail path does not exist here.** `inbound/authenticity.ts` spends two
+ * hundred lines earning a customer link from a `From:` header that anybody can write; a submission
+ * arrives on a request `requireAuth()` already proved, so the account is the identity rather than a
+ * guess about it. Everything below is therefore a bound on *volume and shape*, never on identity.
+ *
+ * Bounded separately from `guard` for the same reason it is counted separately: that block exists
+ * because a public address is a public write endpoint, and this surface is neither public nor
+ * anonymous. Abuse here is attributable to an account and revocable with it, which is a materially
+ * different threat model and deserves its own numbers rather than a share of somebody else's.
+ */
+export declare const SupportSubmissionConfig: z.ZodObject<{
+    enabled: z.ZodDefault<z.ZodBoolean>;
+    maxSubjectChars: z.ZodDefault<z.ZodNumber>;
+    maxBodyChars: z.ZodDefault<z.ZodNumber>;
+    maxPerAccountPerHour: z.ZodDefault<z.ZodNumber>;
+    attachments: z.ZodPrefault<z.ZodObject<{
+        enabled: z.ZodDefault<z.ZodBoolean>;
+        maxBytes: z.ZodDefault<z.ZodNumber>;
+        maxCount: z.ZodDefault<z.ZodNumber>;
+        allowedContentTypes: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type SupportSubmissionConfig = z.output<typeof SupportSubmissionConfig>;
+/** How a reply leaves the building. */
+export declare const SupportReplyConfig: z.ZodObject<{
+    enabled: z.ZodDefault<z.ZodBoolean>;
+    replyToAddress: z.ZodPipe<z.ZodOptional<z.ZodString>, z.ZodTransform<string | undefined, string | undefined>>;
+    deliverInApp: z.ZodDefault<z.ZodBoolean>;
+    snippets: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
+        label: z.ZodString;
+        category: z.ZodOptional<z.ZodString>;
+        body: z.ZodString;
+    }, z.core.$strip>>>;
+}, z.core.$strip>;
+export type SupportReplyConfig = z.output<typeof SupportReplyConfig>;
+/**
+ * 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.
+ */
+export declare const SupportSearchConfig: z.ZodObject<{
+    fts: z.ZodDefault<z.ZodBoolean>;
+}, z.core.$strip>;
+export type SupportSearchConfig = z.output<typeof SupportSearchConfig>;
+/** The full support configuration. */
+export declare const SupportConfig: z.ZodObject<{
+    inboundAddresses: z.ZodDefault<z.ZodArray<z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>>>;
+    categories: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodString>>;
+    ai: z.ZodPrefault<z.ZodObject<{
+        enabled: z.ZodDefault<z.ZodBoolean>;
+        model: z.ZodDefault<z.ZodString>;
+        maxChars: z.ZodDefault<z.ZodNumber>;
+        temperature: z.ZodDefault<z.ZodNumber>;
+    }, z.core.$strip>>;
+    attachments: z.ZodPrefault<z.ZodObject<{
+        enabled: z.ZodDefault<z.ZodBoolean>;
+        maxBytes: z.ZodDefault<z.ZodNumber>;
+        maxCount: z.ZodDefault<z.ZodNumber>;
+        retainRaw: z.ZodDefault<z.ZodBoolean>;
+    }, z.core.$strip>>;
+    guard: z.ZodPrefault<z.ZodObject<{
+        maxRawBytes: z.ZodDefault<z.ZodNumber>;
+        maxPerSenderPerHour: z.ZodDefault<z.ZodNumber>;
+        maxPerHour: z.ZodDefault<z.ZodNumber>;
+        trustAuthenticationResults: z.ZodDefault<z.ZodBoolean>;
+        authservId: z.ZodOptional<z.ZodString>;
+        archiveSpam: z.ZodDefault<z.ZodBoolean>;
+    }, z.core.$strip>>;
+    submission: z.ZodPrefault<z.ZodObject<{
+        enabled: z.ZodDefault<z.ZodBoolean>;
+        maxSubjectChars: z.ZodDefault<z.ZodNumber>;
+        maxBodyChars: z.ZodDefault<z.ZodNumber>;
+        maxPerAccountPerHour: z.ZodDefault<z.ZodNumber>;
+        attachments: z.ZodPrefault<z.ZodObject<{
+            enabled: z.ZodDefault<z.ZodBoolean>;
+            maxBytes: z.ZodDefault<z.ZodNumber>;
+            maxCount: z.ZodDefault<z.ZodNumber>;
+            allowedContentTypes: z.ZodDefault<z.ZodArray<z.ZodString>>;
+        }, z.core.$strip>>;
+    }, z.core.$strip>>;
+    reply: z.ZodPrefault<z.ZodObject<{
+        enabled: z.ZodDefault<z.ZodBoolean>;
+        replyToAddress: z.ZodPipe<z.ZodOptional<z.ZodString>, z.ZodTransform<string | undefined, string | undefined>>;
+        deliverInApp: z.ZodDefault<z.ZodBoolean>;
+        snippets: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
+            label: z.ZodString;
+            category: z.ZodOptional<z.ZodString>;
+            body: z.ZodString;
+        }, z.core.$strip>>>;
+    }, z.core.$strip>>;
+    search: z.ZodPrefault<z.ZodObject<{
+        fts: z.ZodDefault<z.ZodBoolean>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type SupportConfig = z.output<typeof SupportConfig>;
+export type SupportConfigInput = z.input<typeof SupportConfig>;
+/**
+ * Would this configuration ever put a byte in `SUPPORT_BUCKET`?
+ *
+ * **The one place the question is answered, because three independent settings answer it and each has
+ * its own writer.** `attachments.enabled` gates stored mail attachments (`inbound/ingest.ts:200`),
+ * `attachments.retainRaw` gates the raw MIME copy (`inbound/ingest.ts:346`), and
+ * `submission.attachments.enabled` gates an in-app submission's files (`submission/submit.ts:268`).
+ * All three default `true`, so the ordinary project is unaffected by this predicate existing.
+ *
+ * Two callers, and they must agree: `capability.ts` declares the binding only when this is true, and
+ * `pithy support provision` creates the bucket only when this is true. They disagreed before #440 —
+ * the provisioner asked about `enabled` and `retainRaw` and never about submissions, so a project that
+ * wanted uploads but no mail attachments got a binding pointing at a bucket nothing had created, and
+ * every submitted file was dropped with a warning. One predicate is what makes that unrepresentable.
+ */
+export declare function supportNeedsBucket(config: SupportConfig): boolean;
+//# sourceMappingURL=config.d.ts.map

package/dist/config/config.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"config.d.ts","sourceRoot":"","sources":["../../src/config/config.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAGxB;;;;;;;;;;GAUG;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,sBAAsB,mCAAmC,CAAC;AAEvE,0DAA0D;AAC1D,eAAO,MAAM,eAAe;;;;;iBA+BkF,CAAC;AAC/G,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,eAAe,CAAC,CAAC;AAE/D,+DAA+D;AAC/D,eAAO,MAAM,wBAAwB;;;;;iBA6BkF,CAAC;AACxH,MAAM,MAAM,wBAAwB,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,wBAAwB,CAAC,CAAC;AAEjF;;;;;GAKG;AACH,eAAO,MAAM,kBAAkB;;;;;;;iBA8C8D,CAAC;AAC9F,MAAM,MAAM,kBAAkB,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAErE;;;;;;;;;;;;;;;GAeG;AACH;;;;;;;GAOG;AACH,eAAO,MAAM,0BAA0B,KAAK,CAAC;AAE7C,eAAO,MAAM,kCAAkC;;;;;iBAkC5C,CAAC;AACJ,MAAM,MAAM,kCAAkC,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,kCAAkC,CAAC,CAAC;AAErG;;;;;;;;;GASG;AACH,eAAO,MAAM,4BAA4B,MAAM,CAAC;AAChD,2FAA2F;AAC3F,eAAO,MAAM,yBAAyB,SAAU,CAAC;AAEjD;;;;;;;;;;;;;GAaG;AAEH,eAAO,MAAM,uBAAuB;;;;;;;;;;;iBAwCjC,CAAC;AACJ,MAAM,MAAM,uBAAuB,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,uBAAuB,CAAC,CAAC;AAE/E,uCAAuC;AACvC,eAAO,MAAM,kBAAkB;;;;;;;;;iBAmC5B,CAAC;AACJ,MAAM,MAAM,kBAAkB,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAErE;;;;;GAKG;AACH,eAAO,MAAM,mBAAmB;;iBAS8D,CAAC;AAC/F,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAEvE,sCAAsC;AACtC,eAAO,MAAM,aAAa;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAiCvB,CAAC;AACJ,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,MAAM,CAAC,OAAO,aAAa,CAAC,CAAC;AAC3D,MAAM,MAAM,kBAAkB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,aAAa,CAAC,CAAC;AAE/D;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,aAAa,GAAG,OAAO,CAEjE"}