@spacefast/common 0.0.26 → 0.2.2

package/dist/contracts/functions.d.ts

@@ -3,46 +3,33 @@ import { type ExecutionCapabilities } from "./execution.js";
 /**
  * Spacefast Functions: tenant workers run as Cloudflare Dynamic Workers.
  *
- * The shape of this product follows from two constraints that are not
- * negotiable and that together rule out the obvious architecture:
+ * Two constraints shape the product:
  *
- * 1. **Cloudflare is reached from wp.cloud, never from the control plane.**
- *    The control plane records intent; the space's own origin performs every
+ * 1. Cloudflare is reached from wp.cloud, never from the control plane. The
+ *    control plane records intent; the space's own origin makes every
  *    Cloudflare call.
- * 2. **Every asset is served by wp.cloud.** We deliberately decline
- *    Cloudflare's static-asset support for user workers. A worker receives
- *    only the requests that could not be answered from bytes on disk, and
- *    `/_next/static/*` and friends never leave our origin.
+ * 2. Every asset is served by wp.cloud. A worker receives only the requests
+ *    that could not be answered from bytes on disk, so `/_next/static/*` and
+ *    friends never leave our origin.
  *
- * Dynamic Workers is what makes both hold at once. There is no upload: a
- * version's bundle stays in its own content store on wp.cloud, and the host
- * worker pulls it on demand through the Worker Loader binding. So there is no
- * script lifecycle here — no namespace, no script name, no tag budget, no
- * eviction, no garbage collection — because there is no artefact of ours living
- * on Cloudflare to manage. What Cloudflare holds is a warm isolate, which is a
- * cache, not a record.
- *
- * That also keeps the exit cheap. The contract below is "here is a module
- * graph, here is its configuration, run it", which is workerd's own shape; the
- * managed runtime is an implementation of it rather than the thing we built
- * against.
- *
- * What the worker gets in exchange is the thing we could not build: a real V8
- * isolate that runs npm packages and framework output — OpenNext Next.js among
- * them — without us having to sandbox any of it.
+ * Dynamic Workers holds both at once. There is no upload: a version's bundle
+ * stays in its own content store on wp.cloud and the host worker pulls it
+ * through the Worker Loader binding, so no artefact of ours lives on Cloudflare
+ * and there is no script lifecycle to manage. What the worker buys is a real V8
+ * isolate running npm packages and framework output, OpenNext Next.js among
+ * them, without us sandboxing any of it.
  *
  * The cost is that the worker is a continent away from the space's MySQL.
  * `ctx.db` therefore travels back over an HTTPS relay to the same PHP broker
  * the local tier speaks to over a pipe, which is slower and batched rather
  * than transactional. That is why capsules are a different product rather
- * than a placement option — see `endpointIsPortable` in `./execution.js`.
+ * than a placement option. See `endpointIsPortable` in `./execution.js`.
  */
 /**
- * The tag a compiled worker artifact carries — in `functionsSourceFinalizeSchema`
- * and the runtime config built from it — so the PHP origin can tell what it is
- * dispatching (`functions-dispatch.php` refuses a config tagged anything else).
- * It is a property of the artifact the tree produced, not a kind a space or a
- * version declares: a publish can carry this beside a capsule.
+ * The tag a compiled worker artifact carries, so the PHP origin can tell what
+ * it is dispatching. `functions-dispatch.php` refuses any other tag. It is a
+ * property of the artifact, not a kind a space or a version declares: a publish
+ * can carry this beside a capsule.
  */
 export declare const FUNCTIONS_RUNTIME_KIND = "functions";
 export declare const FUNCTIONS_SOURCE_METADATA_KEY = "spacefastFunctions";
@@ -52,7 +39,7 @@ export declare const FUNCTIONS_RUNTIME_ROUTE_PATHS: {
     /** Where a dispatched worker calls back for brokered capabilities. */
     readonly relay: "/__spacefast/functions/relay";
     /**
-     * Where the execution host asks the space origin to drop cached responses —
+     * Where the execution host asks the space origin to drop cached responses:
      * an OpenNext `revalidatePath` must reach the CDN in front of wp.cloud, and
      * only the origin can speak for its own cache. Authenticated with the
      * version-scoped purge credential in the `sf-purge-token` request header.
@@ -61,85 +48,140 @@ export declare const FUNCTIONS_RUNTIME_ROUTE_PATHS: {
 };
 /**
  * The header the execution host presents at the origin purge route. Outside the
- * `sf-fx-` namespace on purpose: that prefix names dispatch instructions the
- * origin SENDS, and is stripped from anything inbound before tenant code — a
- * purge call is the host speaking for itself, like a relay call.
+ * `sf-fx-` namespace because that prefix names dispatch instructions the origin
+ * SENDS, and is stripped from anything inbound before tenant code.
  */
 export declare const FUNCTIONS_PURGE_TOKEN_HEADER = "sf-purge-token";
+/**
+ * The credential a space origin presents to the execution host on every
+ * dispatch (`sf-fx-dispatch-token`), and the audience that identifies it.
+ *
+ * It is a PER-SITE token, not a fleet secret. The control plane mints one
+ * Ed25519 JWT per wp.cloud box, bound to that box's `runtime_instance_id`, and
+ * writes it into that box's persistent data. The host verifies the signature
+ * against the control plane's public key and takes the site identity from the
+ * verified claim rather than from anything the caller asserts.
+ *
+ * Tenant PHP runs on the same box and can read the box's own configuration, so
+ * assume the tenant can read this credential. A per-site token read once still
+ * speaks only for its own site: the host refuses any bundle whose signed token
+ * names a different `runtime_instance_id`. Signing is EdDSA rather than HMAC so
+ * that no signing material sits on the edge, where a host compromise would mint
+ * dispatch credentials for the whole fleet.
+ */
+export declare const FUNCTIONS_DISPATCH_TOKEN_AUD = "spacefast-functions-dispatch";
+/**
+ * Pinned by every verifier rather than read from the token's own header.
+ * Accepting the presented `alg` is how `alg: none` forgeries work.
+ */
+export declare const FUNCTIONS_TOKEN_ALG = "EdDSA";
+/**
+ * Ten years, like the bundle and relay credentials: the token is not re-mintable
+ * on any request path. It reaches a box only through a wp.cloud persistent-data
+ * sync at provisioning and on maintenance sweeps, so a shorter clock would take
+ * a quiet box offline rather than protect it. Scope is the boundary, and
+ * rotating the platform signing key invalidates every token at once.
+ */
+export declare const FUNCTIONS_DISPATCH_TOKEN_TTL_SECONDS: number;
+/**
+ * What the execution host requires of a dispatch credential before it believes
+ * anything else in the request. One signing key mints every platform token, so
+ * the pinned audience is what keeps them from meaning one authority.
+ */
+export declare const functionsDispatchTokenClaimsSchema: z.ZodObject<{
+    aud: z.ZodLiteral<"spacefast-functions-dispatch">;
+    runtime_instance_id: z.ZodString;
+    exp: z.ZodNumber;
+    nbf: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type FunctionsDispatchTokenClaims = z.infer<typeof functionsDispatchTokenClaimsSchema>;
+/**
+ * The claims carried by the token inside a signed bundle or seed URL. The
+ * audience stays open because both artifacts share this shape and are separated
+ * by their own audience check at the point of use: a bundle grant must never
+ * authorise a seed read.
+ */
+export declare const functionsArtifactTokenClaimsSchema: z.ZodObject<{
+    aud: z.ZodString;
+    runtime_instance_id: z.ZodString;
+    space_id: z.ZodString;
+    version_id: z.ZodString;
+    sha256: z.ZodString;
+    exp: z.ZodNumber;
+    nbf: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type FunctionsArtifactTokenClaims = z.infer<typeof functionsArtifactTokenClaimsSchema>;
+/**
+ * Whether a compact JWT's protected header declares the one algorithm this
+ * platform signs with. Pinned rather than trusted: a verifier that takes the
+ * token's own word for `alg` accepts `alg: none`.
+ */
+export declare function functionsTokenHeaderIsSigned(headerJson: string): boolean;
+/**
+ * Claim readers for an already signature-verified payload. They live beside the
+ * mint-side constants so the control plane's audiences and the host's required
+ * claims stay one definition rather than two that agree today.
+ */
+export declare function parseFunctionsDispatchTokenClaims(claimsJson: string): FunctionsDispatchTokenClaims | null;
+export declare function parseFunctionsArtifactTokenClaims(claimsJson: string): FunctionsArtifactTokenClaims | null;
 /**
  * Where invocation counts are reported, on the CONTROL PLANE rather than the
- * space origin.
- *
- * The two destinations are separate on purpose. Logs are the tenant's content
- * and stay on their own origin; usage is a number the platform bills from and
- * goes straight to us. Sharing one channel would make either destination a
- * plausible place to look for the other's data, and would put log volume on the
- * path that has to stay cheap.
+ * space origin. Logs are the tenant's content and stay on their own origin;
+ * usage is a number the platform bills from. One shared channel would put log
+ * volume on the path that has to stay cheap.
  */
 export declare const FUNCTIONS_USAGE_INTAKE_PATH = "/v1/runtime/functions/usage";
 /** Public, signed read path. Distinct from storage so the token is never a filename. */
 export declare const FUNCTIONS_BUNDLE_ROUTE_PREFIX = "/__spacefast/functions/b";
 export declare const FUNCTIONS_RUNTIME_STORAGE_ROOT = "__spacefast/functions";
 /**
- * Where a version's compiled bundle lives.
- *
- * Under the same `__spacefast/` prefix as every other platform-owned path, so
- * there is one convention rather than one per product. Two consequences fall
- * out of that placement, and both are wanted:
- *
- * - It is not servable as static content. The runtime treats the whole prefix
- *   as control paths, so a tenant's compiled source is not readable at a
- *   guessable URL — and the digest that would make it guessable appears in
- *   build output.
- * - It is written by the ordinary publish path anyway. The upload policy
- *   carves out exactly this subtree (`publish-policy.ts`), so the bundle rides
- *   the normal manifest and upload passes instead of needing a parallel one.
- *
- * The dispatch configuration — host, capabilities, relay credential — is not
- * here and is not content at all. The engine writes it beside the version's
- * file tree rather than inside it, exactly as it does for Zero, so a publish
- * cannot reach it: no carve-out, no upload path, nothing to guard. A publish
- * able to write that file would be a publish able to grant itself authority it
- * was never given.
+ * Where a version's compiled bundle lives, under the same `__spacefast/` prefix
+ * as every other platform-owned path. Two consequences, both wanted:
+ *
+ * - Not servable as static content. The runtime treats the whole prefix as
+ *   control paths, so a tenant's compiled source is not readable at a guessable
+ *   URL, and the digest that would make it guessable appears in build output.
+ * - Written by the ordinary publish path. The upload policy carves out exactly
+ *   this subtree (`publish-policy.ts`), so the bundle rides the normal manifest
+ *   and upload passes.
+ *
+ * The dispatch configuration is not here and is not content at all. The engine
+ * writes it beside the version's file tree, as it does for Zero, so a publish
+ * cannot reach it and cannot grant itself authority it was never given.
  */
 export declare const FUNCTIONS_RUNTIME_BUNDLE_ROOT = "__spacefast/functions/bundles";
 /**
- * Where a version's Next-cache seed document lives — the build-time prerender
- * and fetch-cache entries that warm the execution host's cache object so the
- * first visitor gets the page the build rendered instead of a live re-render.
- * A sibling of `bundles/` with the same properties: publishable through the
- * ordinary upload path (its own carve-out in publish-policy), never servable
- * as static content, read back only through the signed artifact route.
+ * Where a version's Next-cache seed document lives: the build-time prerender
+ * and fetch-cache entries that warm the execution host's cache object, so the
+ * first visitor gets the page the build rendered. A sibling of `bundles/` with
+ * the same properties, publishable through the ordinary upload path with its
+ * own carve-out in publish-policy, never servable as static content, read back
+ * only through the signed artifact route.
  */
 export declare const FUNCTIONS_RUNTIME_SEED_ROOT = "__spacefast/functions/seeds";
 export declare const FUNCTIONS_BUNDLE_FORMAT = "spacefast.functions.bundle.v1";
 export declare const FUNCTIONS_SEED_FORMAT = "spacefast.functions.seed.v1";
 /**
- * Ceiling on a bundle's decoded size.
- *
- * The whole module graph arrives in one response so a cold isolate costs a
- * single round trip, which means this number is also how much the host holds in
- * memory before instantiating anything. Set below the runtime's own script
- * limit so an oversized build fails in our tooling, where we can say which
+ * Ceiling on a bundle's decoded size, and so on how much the host holds in
+ * memory before instantiating: the whole module graph arrives in one response,
+ * so a cold isolate costs a single round trip. Set below the runtime's own
+ * script limit, so an oversized build fails in our tooling, which can say which
  * modules are large, rather than at dispatch, where the tenant sees a 502.
  */
 export declare const FUNCTIONS_BUNDLE_MAX_BYTES: number;
 /**
- * Ceilings on the cache seed document. Per-entry mirrors the cache object's
- * own row limit (an entry the object would refuse is dead weight in the
- * document); the total bounds what the host pulls and ingests on a cold
- * cache. Both are enforced in the CLI, where an overflow can say WHICH pages
- * were left out — an omitted entry is not an error, it just renders live on
- * first request like any cache miss.
+ * Ceilings on the cache seed document. Per-entry mirrors the cache object's own
+ * row limit; the total bounds what the host pulls and ingests on a cold cache.
+ * Both are enforced in the CLI, where an overflow can say WHICH pages were left
+ * out. An omitted entry renders live on first request like any cache miss.
  */
 export declare const FUNCTIONS_SEED_ENTRY_MAX_BYTES: number;
 export declare const FUNCTIONS_SEED_MAX_BYTES: number;
 /**
- * One warm-cache entry: exactly what the runtime's incremental-cache client
- * would have written for `key` had it rendered the page itself. `valueJson`
- * is carried as the JSON string it already is on disk (OpenNext's `.cache` /
- * fetch-cache files) — re-parsing it here would only invite the seed writer
- * and the cache client to disagree about serialization.
+ * One warm-cache entry: what the runtime's incremental-cache client would have
+ * written for `key` had it rendered the page itself. `valueJson` stays the JSON
+ * string it already is on disk (OpenNext's `.cache` / fetch-cache files), so the
+ * seed writer and the cache client cannot disagree about serialization.
  */
 export declare const functionsSeedEntrySchema: z.ZodObject<{
     key: z.ZodString;
@@ -166,25 +208,20 @@ export declare const functionsSeedManifestSchema: z.ZodObject<{
 }, z.core.$strict>;
 export type FunctionsSeedManifest = z.infer<typeof functionsSeedManifestSchema>;
 /**
- * How many entries the origin's dispatch table accepts.
- *
- * Exported because the CLI classifier has to compact its route claims BEFORE
- * assembling the artifact — discovering the ceiling as a validation error at
- * finalize would mean a build that classified fine fails at the last step — so
- * the ceiling has to be a value both sides can read, not a literal each side
- * spells for itself.
+ * How many entries the origin's dispatch table accepts. Exported because the CLI
+ * classifier compacts its route claims BEFORE assembling the artifact: meeting
+ * the ceiling as a finalize error would fail a build that classified fine.
  */
 export declare const FUNCTIONS_MAX_ROUTES = 256;
 /**
- * A worker's dynamic route table. Anything not matched here is answered from
- * the version's static content by wp.cloud and never reaches Cloudflare, which
- * is both the cheaper path and the one that keeps assets ours.
+ * A worker's dynamic route table. Anything not matched here is answered from the
+ * version's static content by wp.cloud and never reaches Cloudflare.
  *
  * A `subtree` entry covers its own path AND everything below it: the engine
  * expands one into both `path` and `path/:splat`
- * (`_stattic_runtime_functions_routes_artifact`, runtime/engine/admin/management.php),
- * which is why `wholeSiteRoutes()` is a single `/` subtree entry and why an
- * exact entry beside a subtree entry at the same path is dead weight.
+ * (`_stattic_runtime_functions_routes_artifact`, runtime/engine/admin/management.php).
+ * So `wholeSiteRoutes()` is a single `/` subtree entry, and an exact entry beside
+ * a subtree entry at the same path is dead weight.
  */
 export declare const functionsRouteSchema: z.ZodObject<{
     method: z.ZodDefault<z.ZodNullable<z.ZodEnum<{
@@ -223,12 +260,9 @@ export declare const functionsBundleModuleSchema: z.ZodUnion<readonly [z.ZodObje
 }, z.core.$strict>]>;
 export type FunctionsBundleModule = z.infer<typeof functionsBundleModuleSchema>;
 /**
- * The document served at a bundle URL and parsed by the host.
- *
- * Both sides of that exchange validate against this schema, which is the point
- * of it living here: the CLI's bundler and the host's loader are separate
- * deployments that must agree, and the only thing keeping them honest is a
- * shared definition of the bytes in between.
+ * The document served at a bundle URL and parsed by the host. The CLI's bundler
+ * and the host's loader are separate deployments, and this shared definition is
+ * the only thing keeping them agreed on the bytes in between.
  */
 export declare const functionsBundleManifestSchema: z.ZodObject<{
     format: z.ZodLiteral<"spacefast.functions.bundle.v1">;
@@ -250,10 +284,9 @@ export declare const functionsBundleManifestSchema: z.ZodObject<{
 export type FunctionsBundleManifest = z.infer<typeof functionsBundleManifestSchema>;
 /**
  * Where the worker's compiled bytes live in the version's own content store.
- * Unlike Zero's bundles these are not carried inline in the finalize payload:
- * framework output routinely runs to megabytes, and inlining it would put the
- * whole thing through the control plane, which the direct-from-wp.cloud rule
- * forbids.
+ * Not inline in the finalize payload like Zero's bundles: framework output runs
+ * to megabytes, and inlining it would push the whole thing through the control
+ * plane, which the direct-from-wp.cloud rule forbids.
  */
 export declare const functionsBundleRefSchema: z.ZodObject<{
     path: z.ZodString;
@@ -262,9 +295,9 @@ export declare const functionsBundleRefSchema: z.ZodObject<{
 }, z.core.$strict>;
 export type FunctionsBundleRef = z.infer<typeof functionsBundleRefSchema>;
 /**
- * Where a version's cache seed document sits in its content store — the
- * bundle ref's sibling, with the seed's own root and ceiling. `entries` is
- * carried so status surfaces can say what the seed holds without fetching it.
+ * Where a version's cache seed document sits in its content store, the bundle
+ * ref's sibling with the seed's own root and ceiling. `entries` is carried so
+ * status surfaces can say what the seed holds without fetching it.
  */
 export declare const functionsSeedRefSchema: z.ZodObject<{
     path: z.ZodString;
@@ -274,41 +307,36 @@ export declare const functionsSeedRefSchema: z.ZodObject<{
 }, z.core.$strict>;
 export type FunctionsSeedRef = z.infer<typeof functionsSeedRefSchema>;
 /**
- * The path a bundle is served from.
- *
- * Content-addressed, so the response is immutable and can be cached at our edge
- * forever — a cold isolate anywhere in the world costs one CDN hit rather than
- * a round trip to the space's origin.
- *
- * The token rides in the path rather than the query string for exactly that
- * reason: a query parameter is subject to cache-key normalisation, and a token
- * that gets stripped from the key would let one space's cached bundle answer
- * another space's URL.
- *
- * Both halves are load-bearing. The digest alone is unguessable to anyone who
- * lacks the bytes, but it is derivable by anyone who *has* them, and it shows up
- * in build output and `sf runtime status`. The token adds the dimension the
- * digest cannot: holding the code does not entitle you to fetch it from us, and
- * rotating the site secret invalidates every URL at once.
+ * The path a bundle is served from. Content-addressed, so the response is
+ * immutable and cacheable at our edge forever: a cold isolate anywhere costs one
+ * CDN hit rather than a round trip to the space's origin.
+ *
+ * The token rides in the path rather than the query string for the same reason.
+ * A query parameter is subject to cache-key normalisation, and a token stripped
+ * from the key would let one space's cached bundle answer another space's URL.
+ *
+ * Both halves are load-bearing. The digest is derivable by anyone holding the
+ * bytes and shows up in build output and `sf runtime status`. The token adds
+ * what the digest cannot: holding the code does not entitle you to fetch it from
+ * us, and rotating the site secret invalidates every URL at once.
  */
 export declare function functionsBundlePath(input: {
     sha256: string;
     token: string;
 }): string;
 /**
- * The seed document's read path — the bundle route with a different terminal
- * filename and its own token audience. One signed artifact route on the
- * origin serves both: the filename says what the digest names, the token's
- * audience says what the caller was authorised to read.
+ * The seed document's read path: the bundle route with a different terminal
+ * filename and its own token audience. One signed artifact route on the origin
+ * serves both.
  */
 export declare function functionsSeedPath(input: {
     sha256: string;
     token: string;
 }): string;
 /**
- * Where the bundle actually sits in the published version — the same path minus
- * the token segment. The token authorises the read; it does not name the file,
- * so rotating the signing key changes every URL without moving a single byte.
+ * Where the bundle sits in the published version, the same path minus the token
+ * segment. The token authorises the read; it does not name the file, so rotating
+ * the signing key changes every URL without moving a byte.
  */
 export declare function functionsBundleStoragePath(input: {
     sha256: string;
@@ -359,6 +387,7 @@ export declare const functionsWorkerArtifactSchema: z.ZodObject<{
         gravatar: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         spam: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         email: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
+        content: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
     }, z.core.$strip>>;
     platform: z.ZodDefault<z.ZodObject<{
         nextCache: z.ZodDefault<z.ZodBoolean>;
@@ -367,12 +396,10 @@ export declare const functionsWorkerArtifactSchema: z.ZodObject<{
 export type FunctionsWorkerArtifact = z.infer<typeof functionsWorkerArtifactSchema>;
 /**
  * The authority a dispatched worker may exercise, in the vocabulary the host
- * speaks on the wire.
- *
- * Deliberately a different, narrower list than `executionCapabilitiesSchema`.
- * That one records what a build *declared* it uses; this one is what the origin
- * *grants*, resolved by the control plane at finalize so the origin forwards a
- * decision rather than making one. Anything absent fails closed at the relay.
+ * speaks on the wire. Narrower than `executionCapabilitiesSchema`, which records
+ * what a build *declared* it uses; this is what the origin *grants*, resolved by
+ * the control plane at finalize so the origin forwards a decision rather than
+ * making one. Anything absent fails closed at the relay.
  */
 export declare const FUNCTIONS_DISPATCH_CAPABILITIES: readonly ["storage.read", "storage.write", "db.read", "db.write", "fetch", "log", "next.cache", "gravatar.profile", "spam.check", "email.send"];
 export declare const functionsDispatchCapabilitySchema: z.ZodEnum<{
@@ -391,24 +418,17 @@ export type FunctionsDispatchCapability = z.infer<typeof functionsDispatchCapabi
 /**
  * Resolves a build's declared capabilities into the grant a dispatch carries.
  *
- * Three declared capabilities have no dispatch counterpart, each for its own
- * reason:
+ * Three declared capabilities have no dispatch counterpart:
  *
  * - `env` is not a runtime call at all. Values are resolved at finalize and
  *   travel in the config, so a worker reading `env` reaches nothing.
- * - `auth` and `realtime` bind a handler to the local tier — see
- *   `endpointIsPortable` — so code declaring them deploys as a capsule and
- *   never arrives here.
+ * - `auth` and `realtime` bind a handler to the local tier, so code declaring
+ *   them deploys as a capsule and never arrives here. See `endpointIsPortable`.
  *
- * `db` widens to both read and write because a declaration says a handler
- * touches the database, not how. Narrowing it would take per-statement analysis
- * we do not do, and guessing "read-only" from a declaration would be a grant
- * the author never asked for and cannot see.
- *
- * The three platform-service grants are named for the operation an author
- * reaches for, and each covers its service's whole operation set for the same
- * reason `db` widens: a declaration says a handler uses spam checking, not that
- * it never files a correction.
+ * `db` widens to both read and write, and each platform-service grant covers its
+ * service's whole operation set, because a declaration says a handler touches
+ * the database or checks for spam, not how. Narrowing would take per-statement
+ * analysis we do not do.
  */
 export declare function functionsDispatchCapabilities(capabilities: ExecutionCapabilities, platform?: {
     nextCache?: boolean;
@@ -416,12 +436,11 @@ export declare function functionsDispatchCapabilities(capabilities: ExecutionCap
 /** Logs and the host-local Next cache do not transit the origin relay. */
 export declare function functionsGrantNeedsRelay(granted: readonly FunctionsDispatchCapability[]): boolean;
 /**
- * What the space origin needs in order to dispatch to the host on its own. The
- * shared secret is a wp.cloud site secret; it is never part of a version's
- * content and never reaches tenant code, so it is not modelled here.
- *
- * There is no account id and no namespace: the origin talks to one host worker
- * over HTTPS and holds no Cloudflare API credential at all.
+ * What the space origin needs to dispatch to the host on its own. The shared
+ * secret is a wp.cloud site secret, never part of a version's content and never
+ * reachable by tenant code, so it is not modelled here. There is no account id
+ * and no namespace: the origin talks to one host worker over HTTPS and holds no
+ * Cloudflare API credential.
  */
 export declare const functionsHostConfigSchema: z.ZodObject<{
     hostname: z.ZodString;
@@ -432,13 +451,11 @@ export type FunctionsHostConfig = z.infer<typeof functionsHostConfigSchema>;
 /**
  * The callback a dispatched worker uses for `ctx.db`, `ctx.fetch` and logging.
  *
- * Each relay call re-enters the space's PHP-FPM pool, which is the deadlock
- * hazard this product's admission control exists to bound: a proxied request
- * occupies a worker for its whole life while its relay calls demand more. The
- * batching allowance below is the other half of the answer — a handler that
- * issues twenty statements must cost one relay round trip, not twenty. Measured
- * against the PHP broker, batching twenty writes into one call is 8.3x faster
- * than twenty separate ones.
+ * Each relay call re-enters the space's PHP-FPM pool, the deadlock hazard this
+ * product's admission control bounds: a proxied request occupies a worker for
+ * its whole life while its relay calls demand more. Batching is the other half.
+ * Against the PHP broker, twenty writes in one call is 8.3x faster than twenty
+ * separate ones.
  */
 export declare const functionsRelayConfigSchema: z.ZodObject<{
     url: z.ZodString;
@@ -448,12 +465,10 @@ export declare const functionsRelayConfigSchema: z.ZodObject<{
 }, z.core.$strict>;
 export type FunctionsRelayConfig = z.infer<typeof functionsRelayConfigSchema>;
 /**
- * Where the execution host reports how much this version ran.
- *
- * Absent means uncounted, not refused: a space whose configuration predates
- * usage reporting must keep serving, and an execution tier that cannot reach
- * the control plane must never fail a request over it. Counting is reporting
- * only — nothing here throttles, and no limit is enforced anywhere from it.
+ * Where the execution host reports how much this version ran. Absent means
+ * uncounted, not refused: a space whose configuration predates usage reporting
+ * must keep serving, and a tier that cannot reach the control plane must never
+ * fail a request over it. Nothing here throttles.
  */
 export declare const functionsUsageConfigSchema: z.ZodObject<{
     url: z.ZodString;
@@ -464,28 +479,25 @@ export type FunctionsUsageConfig = z.infer<typeof functionsUsageConfigSchema>;
  * The credential the execution host presents at the origin's purge route.
  *
  * Only the token lives here: the purge route is on whichever hostname the
- * visitor actually hit, so the origin composes the URL from the request host at
- * dispatch time — exactly as it does for log intake — instead of freezing one
- * hostname at finalize. A third credential rather than a reuse of the relay's,
- * for the relay's own reason: purging cached responses is a distinct authority,
- * and a worker whose relay is unusable must still be able to invalidate what it
- * rendered. Version-scoped and folded into the host's isolate identity like its
- * siblings, so a republish revokes it.
+ * visitor hit, so the origin composes the URL from the request host at dispatch
+ * time rather than freezing one hostname at finalize. A third credential rather
+ * than a reuse of the relay's, because a worker whose relay is unusable must
+ * still be able to invalidate what it rendered. Version-scoped, so a republish
+ * revokes it.
  */
 export declare const functionsPurgeConfigSchema: z.ZodObject<{
     token: z.ZodString;
 }, z.core.$strict>;
 export type FunctionsPurgeConfig = z.infer<typeof functionsPurgeConfigSchema>;
 /**
- * What a build declares about its worker — everything the CLI can know from the
+ * What a build declares about its worker, everything the CLI can know from the
  * author's project alone.
  *
- * Unlike Zero, this is *not* the same document the runtime receives. A build
- * cannot name the host it will be dispatched to, cannot mint the credential its
- * relay calls will carry, and cannot decide what authority it is granted; all
- * three are the platform's to say. Keeping them out of this schema is what makes
- * that structural rather than a convention — a version's own metadata has no
- * field in which to assert authority it was not given.
+ * Unlike Zero, this is *not* the document the runtime receives. A build cannot
+ * name the host it is dispatched to, mint the credential its relay calls carry,
+ * or decide what authority it is granted. Keeping all three out of this schema
+ * leaves a version's own metadata no field in which to assert authority it was
+ * not given.
  */
 export declare const functionsSourceFinalizeSchema: z.ZodObject<{
     runtimeKind: z.ZodLiteral<"functions">;
@@ -531,6 +543,7 @@ export declare const functionsSourceFinalizeSchema: z.ZodObject<{
             gravatar: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             spam: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             email: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
+            content: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         }, z.core.$strip>>;
         platform: z.ZodDefault<z.ZodObject<{
             nextCache: z.ZodDefault<z.ZodBoolean>;
@@ -546,10 +559,9 @@ export type FunctionsSourceFinalize = z.infer<typeof functionsSourceFinalizeSche
  * The document the control plane sends to the runtime, which the engine stores
  * beside the version's files and the origin reads on every dispatch.
  *
- * It is the build's declaration plus the things only the platform can supply:
- * where to dispatch, what the worker is allowed to do, the credentials that let
- * it do those things and report what it did, and the resolved values of its
- * variables.
+ * It is the build's declaration plus what only the platform can supply: where to
+ * dispatch, what the worker may do, the credentials for doing and reporting it,
+ * and the resolved variable values.
  */
 export declare const functionsRuntimeConfigSchema: z.ZodObject<{
     runtimeKind: z.ZodLiteral<"functions">;
@@ -595,6 +607,7 @@ export declare const functionsRuntimeConfigSchema: z.ZodObject<{
             gravatar: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             spam: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             email: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
+            content: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         }, z.core.$strip>>;
         platform: z.ZodDefault<z.ZodObject<{
             nextCache: z.ZodDefault<z.ZodBoolean>;
@@ -683,6 +696,7 @@ export declare const functionsDeployMetadataSchema: z.ZodObject<{
                 gravatar: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
                 spam: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
                 email: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
+                content: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
             }, z.core.$strip>>;
             platform: z.ZodDefault<z.ZodObject<{
                 nextCache: z.ZodDefault<z.ZodBoolean>;
@@ -696,11 +710,9 @@ export declare const functionsDeployMetadataSchema: z.ZodObject<{
 }, z.core.$strict>;
 export type FunctionsDeployMetadata = z.infer<typeof functionsDeployMetadataSchema>;
 /**
- * Builds the declaration a publish attaches to its version.
- *
- * Exists so the CLI's publish step and every test that needs a Functions
- * version agree on the shape by construction rather than by copying an object
- * literal around — the same reason `createZeroRuntimeFinalizePayload` exists.
+ * Builds the declaration a publish attaches to its version, so the CLI's publish
+ * step and every test needing a Functions version agree on the shape by
+ * construction. Mirrors `createZeroRuntimeFinalizePayload`.
  */
 export declare function createFunctionsSourceFinalize(input: {
     appName: string;
@@ -718,12 +730,9 @@ export declare function createFunctionsSourceFinalize(input: {
 }): FunctionsSourceFinalize;
 /**
  * What a version's worker is currently doing, as an observer of the space can
- * actually determine.
- *
- * There is no upload state to report. A bundle is either in the version's
- * content store or it is not, and dispatch is decided by which version is
- * serving — so these three cover the whole space of answers, and each one is
- * checkable rather than inferred from a job we ran earlier.
+ * determine. There is no upload state: a bundle is either in the version's
+ * content store or it is not, and dispatch follows whichever version is serving,
+ * so each of these three is checkable rather than inferred from an earlier job.
  */
 export declare const functionsExecutionStateSchema: z.ZodEnum<{
     ready: "ready";
@@ -734,17 +743,14 @@ export type FunctionsExecutionState = z.infer<typeof functionsExecutionStateSche
 /**
  * What a live worker is, as the `worker` member of a space's runtime status.
  *
- * It carries no kind tag. The member it rides in already says which product
- * answered, and the same tree can carry a capsule beside it — a discriminant
- * here could only repeat the field name or contradict its sibling.
- *
- * No `versionId`: the status response it rides in already names the live
- * version.
+ * No kind tag: the member it rides in already says which product answered, and
+ * the same tree can carry a capsule beside it. No `versionId`: the status
+ * response already names the live version. No `database` field:
+ * `capabilities.db` is the fact the whole `/db` family branches on, and stating
+ * it twice invites the two to disagree.
  *
- * Everything but `executionState` is a field of the version's own finalize
- * metadata, so this answers whether or not the origin is reachable. There is no
- * `database` field: `capabilities.db` is the fact the whole `/db` family
- * branches on, and stating it twice invites the two to disagree.
+ * Everything but `executionState` comes from the version's finalize metadata, so
+ * this answers whether or not the origin is reachable.
  */
 export declare const functionsAppSchema: z.ZodObject<{
     artifactId: z.ZodString;
@@ -775,6 +781,7 @@ export declare const functionsAppSchema: z.ZodObject<{
         gravatar: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         spam: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
         email: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
+        content: z.ZodOptional<z.ZodDefault<z.ZodBoolean>>;
     }, z.core.$strip>>;
     executionState: z.ZodEnum<{
         ready: "ready";