primitive-admin 1.1.0-alpha.9 → 1.1.0

package/dist/src/lib/generated-config-surfaces.d.ts

@@ -0,0 +1,2936 @@
+/**
+ * GENERATED FILE — DO NOT EDIT BY HAND.
+ *
+ * Vendored from the canonical server modules under `src/config-surface/` — the
+ * ONE definition per configuration object (issue #2644). The server's
+ * create/update handlers and this copy read the same field surface, so the CLI's
+ * push payloads, pull serializers and TOML key validation cannot drift from what
+ * the server accepts.
+ *
+ * Regenerate with:
+ *   node cli/scripts/gen-config-surfaces.mjs   (runs automatically at CLI prebuild)
+ *
+ * A freshness guard (`gen-config-surfaces.mjs --check`, asserted by
+ * `cli/tests/unit/config-surface-drift-guard.test.ts`) fails if this committed
+ * copy does not match the source.
+ */
+/**
+ * The one definition per configuration object (issue #2644).
+ *
+ * A "configuration object" is anything `primitive config` round-trips as
+ * config-as-code: workflows, prompts, integrations, webhooks, cron triggers,
+ * blob buckets, database types, rule sets, email templates, and the type
+ * configs. Every one of them used to write its field surface out by hand in at
+ * least three places — the server's create/update handler, the CLI's push
+ * payload builder, and the CLI's pull serializer — so adding a field to one and
+ * not the others failed silently: the field was simply absent, `config diff` could
+ * not see it, and a pull → push cycle cleared it server-side (#571, #807, #1081,
+ * #1172, #1177, #1972, #2635).
+ *
+ * These types describe that surface ONCE. The definitions live here on the
+ * server; the CLI vendors them at build time into
+ * `cli/src/lib/generated-config-surfaces.ts`
+ * (`cli/scripts/gen-config-surfaces.mjs`), the same server→CLI vendoring
+ * `gen-operation-def-descriptor.mjs` (#1544) already uses, so the published CLI
+ * still imports no server code at runtime.
+ *
+ * ── Scope: declarative classification and coverage ONLY ──────────────────
+ * Decision of record (#1976, 2026-07-23, carried forward at #2644's design
+ * gate): a definition records WHICH fields exist, whether each is part of the
+ * TOML surface, which modes the server accepts it in, and — for a field with
+ * real behavior — the NAME of the handler that owns that behavior. It never
+ * encodes the behavior itself, and no handler source is ever regex-scanned for
+ * field names. `pickWritableFields` replaces the key list, not the validation.
+ *
+ * ── Purity ───────────────────────────────────────────────────────────────
+ * Everything under `src/config-surface/` must stay importable by a build-time
+ * Node script with no Workers runtime: no `getAppModels`, no `withAppContext`,
+ * no `src/do-routing.ts`, no `env`. `cli/tests/unit/config-surface-drift-guard.test.ts`
+ * asserts the directory's import graph stays empty of those modules.
+ */
+/** Value shape of a field on the wire and in TOML. Descriptive, not a parser. */
+export type FieldType = "string" | "number" | "boolean" | "string[]" | "json";
+/**
+ * Why a persisted field is not part of the TOML surface. `note` is required —
+ * absence from a hand-written list is never a decision (#2644 criterion 4).
+ */
+export type NotExposed = {
+    kind: "server-owned";
+    note: string;
+} | {
+    kind: "structural";
+    note: string;
+    /**
+     * Which create/update modes carry this key IN THE REQUEST BODY — the same
+     * statement `ConfigField.writableOn` makes about a field, for a key that
+     * is not part of the TOML field surface.
+     *
+     * Omitted means both, the common case for a sub-tree the body always
+     * carries (`rules`, `metadataManifest`, `config`). `[]` says the key
+     * never travels in the body at all: it is in the URL path or comes from
+     * the file name, so no request schema admits it. Being structural is a
+     * statement about the TOML surface and does not by itself make a key
+     * writable — a mode whose handler never reads the key is not declared
+     * for it, or the schema would accept a key the handler drops, which is
+     * the silent 200 criterion 9 exists to end.
+     */
+    requestModes?: readonly ("create" | "update")[];
+} | {
+    kind: "secret";
+    note: string;
+} | {
+    kind: "deprecated";
+    note: string;
+};
+export interface ConfigField {
+    /** `models.yaml` field name === the wire key on create/update. */
+    field: string;
+    /** Key inside the TOML table (often identical to `field`). */
+    tomlKey: string;
+    /**
+     * The SUB-TABLE inside this field's table that the key is authored under
+     * (#3626) — `tomlGroup: "chat"` means `[configs.chat].systemPrompt` rather
+     * than `systemPrompt` at the `[[configs]]` root.
+     *
+     * A statement of WHERE a key is authored and nothing else (#1976): the pull
+     * projection writes it there, the push builder reads it from there, the
+     * unknown-key check stops accepting it at the root, and the declared-type
+     * check labels it with the group. No behavior is attached, and the WIRE stays
+     * flat — the admin and app API bodies carry `systemPrompt` beside `questions`
+     * exactly as before, each its own typed column.
+     *
+     * Prompts are the first object to need it: a prompt declares a `kind` and a
+     * `[[configs]]` entry may carry only the block named by that kind, so the
+     * next kind (embeddings, rerank) is a group declaration plus its fields
+     * rather than another round of implicit discrimination.
+     *
+     * The group must be declared in the table's `tomlGroups`
+     * (`findBadTomlGroupDeclarations`).
+     *
+     * #3798 — a LIST names a key authored under more than one block: the six
+     * model settings an agent shares with chat are `["chat", "agent"]`. Push
+     * reads the key from whichever of its blocks the entry carries, and pull
+     * writes it under the block the caller names (the prompt's kind), the first
+     * one otherwise. Read it through `tomlGroupsOf`, never directly.
+     */
+    tomlGroup?: string | readonly string[];
+    type: FieldType;
+    /** "whenSet" omits the key on pull when the value is empty; see #1033's `emit`. */
+    emit: "always" | "whenSet";
+    /**
+     * Modes the SERVER accepts the field in — a statement about the handler's
+     * `hasOwnProperty` branches and nothing else. `["create"]` means update
+     * genuinely rejects/ignores it (e.g. an immutable key). It is NOT a place to
+     * record CLI call ordering: `syncCallable` is accepted on both create and
+     * update (`src/admin-api.ts` `createAppWorkflow` / `updateAppWorkflow`); the
+     * CLI's create-only send is a *sequencing* invariant owned by
+     * `applyWorkflowBody` (#807 — the deferred second PATCH is itself an update
+     * call, and would break if update rejected the field).
+     */
+    writableOn: readonly ("create" | "update")[];
+    /**
+     * Classification, not dispatch. "passthrough" = the accepted value is stored
+     * as-is. Otherwise the named handler owns validation, normalization and
+     * serialization for this field; the guard only asserts the export exists.
+     *
+     * A handler is named `"<repo-relative module path>#<exported name>"`, e.g.
+     * `"src/workflows/config/workflow-field-handlers.ts#normalizeWorkflowStatus"`.
+     * `cli/tests/unit/config-surface-drift-guard.test.ts` fails when the module or
+     * the export is missing (#2644 behavior 2b).
+     *
+     * `stage` says WHEN the handler runs, with exactly the meaning `RuleStage`
+     * gives a cross-field rule (#3375). Until this issue the slot named an owner
+     * and never said when, so intent criterion 5 — "a rule declared `preflight`
+     * is provably reached before the first mutating call" — could not cover a
+     * single-field rule at all. It is REQUIRED, so a new field handler cannot be
+     * declared without answering the question, and
+     * `findMalformedFieldValidationStages` closes the key set at
+     * `handler`/`stage`: the slot stays declarative like the field entry itself.
+     */
+    validation: "passthrough" | {
+        handler: string;
+        stage: RuleStage;
+    };
+    /**
+     * This field's declared type genuinely admits more than one TOML spelling
+     * (#2880 criterion 5).
+     *
+     * The declared type is the contract: a quoted number for a declared number
+     * is a validation error `config diff` and `config push` report identically,
+     * and neither coerces. A handful of fields are genuinely dual-encoded
+     * anyway — `temperature` and `topP` are `StringField`s the server stores as
+     * strings and returns parsed (#2869), so `"0.2"` and `0.2` describe one
+     * value — and for those the two spellings must compare EQUAL, or diff
+     * reports a `Modified` no push can clear.
+     *
+     * Recorded here rather than inferred from the type, so the carve-out is a
+     * decision with a reason attached instead of a rule that quietly widens to
+     * every number in the surface.
+     */
+    dualEncoded?: {
+        note: string;
+    };
+    /**
+     * The field is still accepted but deprecated, and `note` says what to use
+     * instead (#1815). Unlike `NotExposed`'s `deprecated` kind, the field stays
+     * on the TOML surface: it round-trips on pull and push exactly as before.
+     * The generated request schema marks the key `deprecated: true` in the
+     * published OpenAPI spec. `config push` does not read this note; any push
+     * warning for the field lives in the CLI's push preflight.
+     */
+    deprecated?: {
+        note: string;
+    };
+    /**
+     * The value the SERVER materializes when a create omits this key (#2880
+     * DSO-002).
+     *
+     * A hand-authored file that omits an optional field the server defaults —
+     * an integration's `timeoutMs`, a cron trigger's `timezone` — creates fine
+     * and then reads `Modified` forever: the server holds the default, the file
+     * holds nothing, and push's payload builder drops the absent key so the
+     * difference can never converge. Recording the default here lets the LOCAL
+     * side of the comparison apply the same value the server did.
+     *
+     * Only for a default the server assigns on CREATE and returns on read.
+     */
+    serverDefault?: string | number | boolean;
+}
+export interface ConfigTable {
+    /** TOML path, e.g. ["workflow"] for [workflow], ["configs"] for [[configs]]. */
+    tomlPath: readonly string[];
+    repeated: boolean;
+    /** The `models.yaml` model backing this table — the coverage anchor. */
+    model: string;
+    fields: readonly ConfigField[];
+    /**
+     * The CLOSED set of sub-table names this table's fields may be authored under
+     * (#3626), each with the reason it exists. A field's `tomlGroup` must name
+     * one of these, and a name declared here that no field uses is a failure —
+     * both checked by `findBadTomlGroupDeclarations`, the same rule `notExposed`
+     * follows one level down: absence from a hand-written list is never a
+     * decision.
+     *
+     * Omitted on every table whose keys are all authored at its root, which is
+     * all of them but `prompt`'s `[[configs]]`.
+     */
+    tomlGroups?: Readonly<Record<string, {
+        note: string;
+    }>>;
+    /** Every model field not in `fields`, with its reason. Coverage is exhaustive. */
+    notExposed: Readonly<Record<string, NotExposed>>;
+    /**
+     * TOML keys accepted inside this table that are NOT part of the write field
+     * surface — an author writes them, but some other machinery consumes them.
+     * Declared here so `config push`'s unrecognized-key rejection (#2644 criterion
+     * 6) does not reject a key the CLI itself emits, and so the reason is visible
+     * rather than implied.
+     */
+    tomlOnlyKeys: Readonly<Record<string, NotExposed>>;
+    /**
+     * Keys the create/update BODY carries that are not `models.yaml` fields at
+     * all — protocol keys such as the `expectedModifiedAt` optimistic-concurrency
+     * token. Declared here so phase 5's generated request schemas
+     * (`request-schema.ts`) accept them, with the reason visible rather than
+     * implied. Optional: most objects have none.
+     *
+     * `modes` records which handlers actually read the key, the same statement
+     * `ConfigField.writableOn` makes about a field. Omitted means both — the
+     * common case. A key the handler in this mode does not read is NOT declared
+     * for that mode: the schema would accept it and the handler would drop it,
+     * which is the silent 200 criterion 9 exists to end.
+     */
+    requestOnlyKeys?: Readonly<Record<string, {
+        note: string;
+        modes?: readonly ("create" | "update")[];
+    }>>;
+    /**
+     * Keys the server's GET response carries that are not `models.yaml` fields —
+     * derived flags and related payloads. Declared here so `config pull`'s
+     * unrecognized-key warning (#2644 criterion 6) reports genuinely unknown keys
+     * rather than every computed one.
+     */
+    responseOnlyKeys: Readonly<Record<string, NotExposed>>;
+}
+/**
+ * When a rule is decided (#3373, project `cli-server-rule-parity`).
+ *
+ * `preflight` = decidable from the authored files ALONE and enforced before the
+ * first mutating call on that surface's push path — which implies the handler's
+ * module lives under `src/config-surface/`, so the CLI runs the server's own
+ * copy through the vendored artifact rather than a second implementation.
+ * `apply` = it needs app state (does this secret exist, is this scheme's config
+ * valid under the environment's JWKS policy, per-app caps, key collisions) or
+ * has path semantics only the server can decide.
+ *
+ * Stage is a property of the (surface, rule) PAIR, not of the predicate: the
+ * same file-decidable check is `preflight` on a surface whose CLI path runs it
+ * and `apply` on one whose CLI path does not. Declaring `preflight` where no
+ * CLI call exists would make the registry promise a refusal that in fact lands
+ * mid-apply.
+ */
+export type RuleStage = "preflight" | "apply";
+/**
+ * The cross-field spelling of `RuleStage`, kept as an exported alias.
+ *
+ * #3373 named the type for the only slot that had a stage. #3375 gave
+ * `ConfigField.validation` one too, with the same meaning, so the canonical
+ * name is the general one — and this alias stays because it is part of the
+ * registry's published surface (`CrossFieldRule.stage`, the guard, every
+ * `crossFieldRulesForStage` caller) and renaming it would be a breaking change
+ * to buy a shorter name.
+ */
+export type CrossFieldRuleStage = RuleStage;
+/**
+ * One rule of a configuration object that spans more than one field — `durable
+ * = true` beside a webhook trigger, `runAs = "system"` beside a non-empty
+ * `accessRule`, an HMAC scheme with no `signingSecret`.
+ *
+ * Such a rule belongs to no single field, so `ConfigField.validation` has
+ * nowhere to put it; attaching it to one field arbitrarily would make the
+ * coverage claim a lie. Declaring it here makes the SET of a surface's rules
+ * enumerable, which is what lets `config push`'s two-stage contract be derived
+ * from the registry (`crossFieldRulesForStage`) instead of maintained by hand.
+ *
+ * Classification, not dispatch (#1976 decision of record, carried at #2644 and
+ * again here): the declaration names the ONE export that enforces the rule and
+ * says when it runs. Nothing reads it to decide what to call.
+ */
+export interface CrossFieldRule {
+    /** Stable, kebab-case, unique within the surface: `^[a-z0-9][a-z0-9-]*$`. */
+    id: string;
+    /** One author-facing sentence: what the rule refuses, and why. */
+    description: string;
+    stage: CrossFieldRuleStage;
+    /**
+     * The ONE enforcement point, as `"<repo-relative module>#<export>"` — the
+     * same spelling `ConfigField.validation` uses, written with `enforcedBy()`.
+     * The module is repo-relative, starts with `src/` and ends in `.ts`; a
+     * `preflight` handler's module is under `src/config-surface/`.
+     */
+    handler: string;
+}
+/**
+ * ── The migrated-module convention (#3373) ────────────────────────────────
+ *
+ * Naming a handler cannot catch a NEW refusal added inside an already-claimed
+ * function: a ninth refusal inside an existing export changes no export, no
+ * type and no declaration. A rules module therefore carries an anchor, and
+ * `cli/tests/unit/config-surface-rules-guard-3373.test.ts` checks it:
+ *
+ *   1. The module exports exactly one `export const <NAME>_RULE_IDS = [...] as
+ *      const;` — a literal array, because the union of its members is the whole
+ *      point; `readonly string[]` widens it back to any string.
+ *   2. It derives `type <Name>RuleId = (typeof <NAME>_RULE_IDS)[number]` and
+ *      defines ONE module-local constructor whose id parameter has that type.
+ *      Every refusal is built through it, so a ninth refusal cannot compile
+ *      without a ninth id, which must be in the list, which must match the
+ *      surface declarations — checked in both directions.
+ *   3. No `throw` statement and no `message` object-literal key — in any of its
+ *      three spellings, `message:`, `"message":` and the `{ ruleId, message }`
+ *      shorthand — appears anywhere outside that constructor's body. This is
+ *      the half the type system cannot carry: `throw new Error(...)` or
+ *      `errors.push({ message })` bypasses the constructor while changing no
+ *      export. Reading a refusal apart (`const { message } = refusal`) or
+ *      passing one on (`refuse(id, message)`) is not building one, and passes.
+ *
+ * Migrating the existing rules modules to it is #3374's and later siblings'
+ * work; every new rules module ships with it.
+ */
+export interface ConfigObjectSurface {
+    /** Matches the CLI's `SyncResourceType.label` — e.g. "workflow", "prompt". */
+    label: string;
+    tables: readonly ConfigTable[];
+    /**
+     * Top-level TOML keys the object's FILE carries besides its field tables —
+     * the authored sub-trees that travel on their own channel (`[[steps]]`,
+     * `[requestConfig]`, `[rules]`, `[models.*]`) and the declared-access
+     * manifest's `[metadata]` / `secrets` / `vars` fragments.
+     *
+     * `tomlOnlyKeys` says which keys are accepted INSIDE a table; this says which
+     * keys are accepted at the document root. Together they make `config push`'s
+     * rejection total (design gate, 2026-08-12: push rejects everything
+     * unrecognized): without it a typo'd table header — `[integraton]` — parsed
+     * to a root key nothing checked, so the file pushed as though the real table
+     * were empty and the TOML-owned fields inside it were CLEARED server-side.
+     *
+     * Every entry carries its reason, the same rule `notExposed` follows: a table
+     * that is simply absent from this map must not read as a decision.
+     */
+    tomlDocumentKeys: Readonly<Record<string, NotExposed>>;
+    /**
+     * Declares that this object HAS no TOML field table, with the reason —
+     * required when `tables` is empty and forbidden otherwise.
+     *
+     * `transform` is the case: a `.rhai` file's authored surface is the script
+     * body, so there is no key/value table to define. Saying so here is the same
+     * rule `notExposed` applies to a field, one level up: "absent from the
+     * registry" and "deliberately fieldless" must not look the same (#2644
+     * criterion 4).
+     */
+    noFieldTable?: {
+        note: string;
+    };
+    /**
+     * Every cross-field rule of this object (#3373). Non-empty when present, and
+     * mutually exclusive with `noCrossFieldRules`.
+     */
+    crossFieldRules?: readonly CrossFieldRule[];
+    /**
+     * Declares that this object HAS no cross-field rule, with the reason — the
+     * same rule `noFieldTable` applies to a field table, one level up. Absence of
+     * both slots means "not declared yet", which is what
+     * `CROSS_FIELD_RULES_UNMIGRATED` inventories; it must never read as "no
+     * rules".
+     */
+    noCrossFieldRules?: {
+        note: string;
+    };
+}
+/**
+ * Shared spellings used by every configuration-object definition (issue #2644).
+ *
+ * These live in one module for a mechanical reason as much as a stylistic one:
+ * `cli/scripts/gen-config-surfaces.mjs` concatenates the whole directory into a
+ * single vendored artifact, so a `const handler = …` declared per definition
+ * module would collide as a duplicate identifier the moment a second object was
+ * migrated.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ */
+/** Both write modes — the common case, spelled once. */
+export declare const BOTH: readonly ("create" | "update")[];
+/** Create only: an immutable key or a field the update handler ignores. */
+export declare const CREATE_ONLY: readonly ("create" | "update")[];
+/** Update only: a field the create handler assigns itself. */
+export declare const UPDATE_ONLY: readonly ("create" | "update")[];
+/**
+ * Name the handler that owns a field's validation, normalization and
+ * serialization, as `"<repo-relative module>#<export>"`. Classification only —
+ * the definition never dispatches through it (#1976 decision of record); the
+ * guard asserts the export exists so a renamed handler fails the CLI unit suite
+ * instead of leaving a dangling reference (#2644 behavior 2b).
+ *
+ * `stage` is REQUIRED (#3375): a field handler that does not say when it runs
+ * makes the same empty promise the cross-field slot made before #3373 — it
+ * names an owner, and criterion 5 has nothing to check. A `preflight` handler
+ * is reached from `cli/src/commands/sync.ts#runConfigPushPreflight` before the
+ * first mutating call, which `findUnreachedPreflightRules` proves statically;
+ * an `apply` handler is everything else.
+ */
+export declare function handledBy(modulePath: string, exportName: string, stage: RuleStage): ConfigField["validation"];
+/**
+ * Name the ONE export that enforces a cross-field rule, as
+ * `"<repo-relative module>#<export>"` — the sibling of `handledBy` for a rule
+ * that belongs to no single field (#3373). Classification only: the declaration
+ * never dispatches through it, and the guard asserts the export exists.
+ */
+export declare function enforcedBy(modulePath: string, exportName: string): string;
+/**
+ * The shape a migrated rules module builds its refusals in (#3373).
+ *
+ * `Id` is the union of the module's `*_RULE_IDS` list, so a new refusal branch
+ * cannot compile without naming an id — and a new id fails `cli-unit-tests`
+ * until a surface declares it. See `types.ts` §"The migrated-module convention".
+ */
+export interface RuleRefusal<Id extends string = string> {
+    ruleId: Id;
+    message: string;
+}
+/**
+ * The declared-access manifest's top-level TOML keys (#1304, #1364).
+ *
+ * Five objects carry the same three-key fragment beside their field table —
+ * workflows, database types, and the group / collection / metadata-category
+ * configs — parsed by the one `parseDeclaredAccessManifestToml`. Spelling it
+ * once here keeps `config push`'s document-level rejection from disagreeing with
+ * itself object by object.
+ */
+export declare const DECLARED_ACCESS_MANIFEST_KEYS: Readonly<Record<string, NotExposed>>;
+/**
+ * The accepted-key half of a configuration object's definition (issue #2644).
+ *
+ * `pickWritableFields` answers exactly one question — "is this key writable on
+ * this object in this mode" — so a server handler stops naming the keys it
+ * accepts. What a present key MEANS stays with the per-field handler the
+ * definition names (spec §Contracts, decision of record #1976): the workflow
+ * `status` enum, the non-negative-integer coercion of the queue limits,
+ * `runAs`'s caller|system check, `parseWorkflowLock`, the `capabilities` array
+ * shape and the CEL parse of `accessRule` all stay where they are. The
+ * mechanical win is that a field can no longer be *absent* from the accepted
+ * set.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ */
+export type WriteMode = "create" | "update";
+/** The field names this table accepts on the wire in `mode`, in declaration order. */
+export declare function writableFieldNames(table: ConfigTable, mode: WriteMode): string[];
+/**
+ * The field names the server PERSISTS for this table in `mode`: the writable
+ * fields, plus the `deprecated` classifications — "still writable, superseded
+ * by another field" is what that kind means (`types.ts`), so a superseded key
+ * a handler still honors (`accessPolicy`, `passkeyRpId`) belongs in every
+ * accepted set, and a field that is NOT writable belongs in none of them.
+ *
+ * Stated once here because three consumers need the same answer: the generated
+ * request schemas, `PUT /settings`'s write allow-list, and the guards.
+ */
+export declare function acceptedWriteFieldNames(table: ConfigTable, mode: WriteMode): string[];
+/**
+ * Split a request body into the keys this table accepts in `mode` and the keys
+ * it does not.
+ *
+ * `accepted` preserves the caller's values verbatim — including an explicit
+ * `null` or `false`, which are meaningful (clear / opt-out) and must not be
+ * coalesced away. Only keys the body actually carries appear, so a handler can
+ * keep using presence (`hasOwnProperty`) to distinguish "leave unset" from
+ * "set to null".
+ *
+ * `rejected` is every other key the body carried. Today it is informational;
+ * #2644 phase 5 turns it into a 400 through the generated request schemas.
+ */
+export declare function pickWritableFields(body: Record<string, unknown>, table: ConfigTable, mode: WriteMode): {
+    accepted: Record<string, unknown>;
+    rejected: string[];
+};
+/**
+ * The PASSTHROUGH half of the accepted body: the keys this table declares
+ * `validation: "passthrough"`, writable in `mode`, that the body actually
+ * carries — with their values verbatim.
+ *
+ * This is what makes criterion 1 true rather than aspirational. A handler that
+ * only picked its accepted set still had to name each field again when it built
+ * the row to persist, so a scalar field added to a definition alone was
+ * accepted on the wire and then dropped on the floor. Handlers spread this into
+ * the create/update payload FIRST, so a field with real behavior still lands
+ * through its named handler (whose assignment comes after and wins), and a
+ * plain scalar needs no handler edit at all.
+ *
+ * Values are passed through untouched — including an explicit `null` or
+ * `false`, which are meaningful (clear / opt-out). "Stored as-is" is exactly
+ * what the `passthrough` classification promises.
+ */
+export declare function passthroughFields(body: Record<string, unknown>, table: ConfigTable, mode: WriteMode, options?: {
+    /**
+     * Fields whose PRESENCE semantics this handler owns — it decides, per
+     * value, whether the key is written at all (a falsy `displayName` that
+     * means "leave the stored name alone"). Listing one here keeps the generic
+     * copy from changing what it means.
+     *
+     * This is never a place to list a field the handler does not assign: a
+     * field named here and dropped by the handler is written nowhere, which is
+     * the silent loss the definition exists to prevent. A NEW field needs no
+     * entry — omission is what makes it flow through.
+     */
+    handledHere?: readonly string[];
+}): Record<string, unknown>;
+/** `true` when the body carries `field` and this table accepts it in `mode`. */
+export declare function hasWritableField(accepted: Record<string, unknown>, field: string): boolean;
+/**
+ * Coverage checks over a configuration object's definition (issue #2644,
+ * criteria 2 and 4).
+ *
+ * A definition claims to describe its model's WHOLE field surface. These
+ * functions are what make that claim mean something: every `models.yaml` field
+ * is either exposed in TOML or classified `notExposed` with a reason, in both
+ * directions — a new field nobody classified, and a classification for a field
+ * that no longer exists. `cli/tests/unit/config-surface-drift-guard.test.ts`
+ * asserts them over every registered object, so coverage follows from being a
+ * configuration object rather than from someone adding a per-type guard.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ */
+/**
+ * `models.yaml` field names per model — the coverage anchor, passed in rather
+ * than read here so this module stays pure (the CLI's vendored artifact carries
+ * it as `GENERATED_CONFIG_MODEL_FIELDS`).
+ */
+export type ModelFieldMap = Readonly<Record<string, readonly string[]>>;
+/**
+ * Whether a value counts as unset for an `emit: "whenSet"` field, so `config pull`
+ * omits the key instead of writing a noisy empty one (and `config diff` does not
+ * report a difference that is not there).
+ *
+ * Carried over verbatim from #1033's shipped app-settings descriptor
+ * (`cli/src/lib/app-settings-descriptor.ts`): an empty array and an empty
+ * object are unset, while `false` and `0` are meaningful values and never are.
+ */
+export declare function isEmptyForEmit(value: unknown, type: ConfigField["type"]): boolean;
+/**
+ * A field name whose shape says it carries a credential. Such a field must be
+ * classified explicitly — exposed with a stated reference-only contract, or
+ * `notExposed: { kind: "secret" }` — because a mechanical generalization that
+ * merely omits it would read as "not decided" (#2254, #2256).
+ */
+export declare const SECRETISH_FIELD: RegExp;
+/** Model fields the table neither exposes nor classifies. Non-empty is a failure. */
+export declare function findUnclassifiedFields(table: ConfigTable, modelFields: readonly string[]): string[];
+/**
+ * Classifications that no longer correspond to a model field — i.e. a field
+ * removed from `models.yaml` while the definition still names it. Also a
+ * failure: a stale classification must not silently pass, or the coverage claim
+ * quietly stops meaning anything.
+ */
+export declare function findStaleClassifications(table: ConfigTable, modelFields: readonly string[]): string[];
+/** The models this surface's tables project, in declaration order, deduped. */
+export declare function surfaceModels(surface: ConfigObjectSurface): string[];
+/**
+ * Model fields the whole surface neither exposes nor classifies. Non-empty is
+ * a failure: the CLI would silently ignore them and a pull → push cycle would
+ * clear them (#2644 criterion 2).
+ */
+export declare function findUnclassifiedSurfaceFields(surface: ConfigObjectSurface, modelFields: ModelFieldMap): string[];
+/**
+ * Classifications naming a field the model no longer has — the other direction,
+ * and equally a failure: a stale entry quietly stops meaning anything.
+ */
+export declare function findStaleSurfaceClassifications(surface: ConfigObjectSurface, modelFields: ModelFieldMap): string[];
+/** Fields the surface both exposes and classifies `notExposed`. Ambiguous. */
+export declare function findDoubleClassifiedSurfaceFields(surface: ConfigObjectSurface): string[];
+/**
+ * Secret-adjacent model fields the surface leaves undecided — neither exposed
+ * with a stated contract nor classified `notExposed` (#2254, #2256).
+ */
+export declare function findUnclassifiedSecretishSurfaceFields(surface: ConfigObjectSurface, modelFields: ModelFieldMap): string[];
+/** Fields classified twice — exposed AND `notExposed`. Ambiguous, so a failure. */
+export declare function findDoubleClassifiedFields(table: ConfigTable): string[];
+/**
+ * `notExposed` / `tomlOnlyKeys` / `responseOnlyKeys` entries whose `note` is
+ * missing or blank. A reason is the whole point of the classification.
+ */
+export declare function findReasonlessClassifications(table: ConfigTable): string[];
+/**
+ * Secret-adjacent model fields with no explicit decision — neither an exposed
+ * entry nor a `notExposed` classification. A bare omission is the failure mode
+ * this catches.
+ */
+export declare function findUnclassifiedSecretishFields(table: ConfigTable, modelFields: readonly string[]): string[];
+/**
+ * Every distinct handler reference the table names, as
+ * `"<repo-relative module>#<export>"`. The guard resolves each one and fails
+ * when the module or the export is missing (#2644 behavior 2b).
+ */
+export declare function handlerReferences(table: ConfigTable): string[];
+/**
+ * The blocks a field is authored under, in declaration order: `[]` for a root
+ * key, one name for most grouped keys, several for a key two blocks share
+ * (#3798). Every reader of `tomlGroup` goes through this.
+ */
+export declare function tomlGroupsOf(field: ConfigField): readonly string[];
+/** The group names this table declares, sorted. Empty for an ungrouped table. */
+export declare function tomlGroupNames(table: ConfigTable): string[];
+/** The TOML keys accepted INSIDE `group`: every field that declares it. */
+export declare function acceptedGroupTomlKeys(table: ConfigTable, group: string): Set<string>;
+/**
+ * TOML keys this table accepts AT ITS ROOT: the UNGROUPED fields, the declared
+ * group names, and the declared extras.
+ *
+ * A grouped leaf written at the root (`questions` directly under `[[configs]]`)
+ * is therefore an unknown key rather than one the payload builder silently
+ * ignores (SO3626-013) — the builder reads a grouped field only from
+ * `source[group][tomlKey]`, so accepting it here would drop the author's value
+ * without a word. The nine deprecated flat chat keys stay accepted through
+ * their `tomlOnlyKeys` declarations, which is what keeps old files pushing.
+ */
+export declare function acceptedTomlKeys(table: ConfigTable): Set<string>;
+/**
+ * Keys inside a group table that no field declares under it, as
+ * `"<group>.<key>"` — plus the bare `"<group>"` for a group value that is not a
+ * table at all (`chat = "yes"`), which has no keys to check and would otherwise
+ * be read as an empty block.
+ */
+export declare function findUnknownGroupedTomlKeys(tomlTable: unknown, table: ConfigTable): string[];
+/**
+ * Group declarations that do not hold together: a field naming a group the
+ * table does not declare, a declared group no field is authored under, and a
+ * declaration with no reason. All three are failures, for the reason
+ * `notExposed` carries a note — a name in a list with nothing behind it reads
+ * as a decision and is not one.
+ */
+export declare function findBadTomlGroupDeclarations(table: ConfigTable): string[];
+/** Top-level TOML keys this object's file accepts: its tables plus the extras. */
+export declare function acceptedTomlDocumentKeys(surface: ConfigObjectSurface): Set<string>;
+/**
+ * `tomlDocumentKeys` entries with no reason, and any that merely restate a
+ * field table. Both are failures: a reason is the whole point of the
+ * classification, and a duplicate would let a table's shape check be bypassed
+ * by declaring it twice.
+ */
+export declare function findBadDocumentKeyDeclarations(surface: ConfigObjectSurface): string[];
+/** Root keys of `tomlData` the surface does not declare. `config push` rejects these. */
+export declare function findUnknownTomlDocumentKeys(surface: ConfigObjectSurface, tomlData: unknown): string[];
+export declare function findMisshapenTomlTables(surface: ConfigObjectSurface, tomlData: unknown): Array<{
+    key: string;
+    expected: "table" | "array of tables";
+}>;
+/**
+ * Server-response keys this table recognizes: every model field (exposed or
+ * not) plus the declared response-only keys. `config pull` warns about anything
+ * else instead of dropping it silently (#2644 criterion 6).
+ */
+export declare function recognizedResponseKeys(table: ConfigTable, modelFields: readonly string[]): Set<string>;
+/**
+ * Checks over a configuration object's CROSS-FIELD rule declarations (issue
+ * #3373, project `cli-server-rule-parity` phase 1).
+ *
+ * `coverage.ts` is the field-level twin: it makes "this definition describes the
+ * whole field surface" mean something. These functions do the same job one level
+ * up for rules — a declaration that is malformed, a rule id a module's
+ * `*_RULE_IDS` list does not carry, a list entry no surface declares, a refusal
+ * built outside its module's typed constructor, and a surface that has declared
+ * neither slot while being absent from the unmigrated inventory each return a
+ * failure line. `cli/tests/unit/config-surface-rules-guard-3373.test.ts` asserts
+ * them over the real registry and proves their teeth on synthetic inputs.
+ *
+ * Everything here is a PURE function over values and over module SOURCE TEXT
+ * passed in by the caller: the guard does the filesystem walk, so this module
+ * stays vendorable (see `types.ts` §Purity). Reading source text is the same
+ * kind of structural check the field guard already makes when it confirms a
+ * handler's export is declared — it never scans a handler for field names to
+ * infer behavior (#1976 decision of record).
+ */
+/** The two stages a rule can be declared at, spelled once. */
+export declare const CROSS_FIELD_RULE_STAGES: readonly CrossFieldRuleStage[];
+/** A rule declaration's closed key set — it may not grow behavior knobs. */
+export declare const CROSS_FIELD_RULE_KEYS: readonly string[];
+/** Every rule handler lives on the server, under `src/`, in a `.ts` module. */
+export declare const RULE_HANDLER_MODULE_PREFIX = "src/";
+/** A `preflight` handler is vendored into the CLI, so it lives here. */
+export declare const PREFLIGHT_HANDLER_MODULE_PREFIX = "src/config-surface/";
+/** Rule ids are kebab-case and stable: they are cited in declarations. */
+export declare const CROSS_FIELD_RULE_ID_PATTERN: RegExp;
+/** The suffix that makes a module a rules module for the unclaimed-export check. */
+export declare const RULES_MODULE_SUFFIX = "-rules.ts";
+/**
+ * Is this module a rules module of THIS registry — `<name>-rules.ts` under
+ * `src/config-surface/`?
+ *
+ * The name is the opt-in: everything a rules module exports is a rule, so an
+ * export no surface declares is a rule with no declaration
+ * (`findUnclaimedRuleModuleExports`). Shared predicates and constants therefore
+ * live in a module that is not named `*-rules.ts` —
+ * `webhook-signing-secret.ts` exports `isWholeSecretReference` and its refusal
+ * codes, and must keep being able to.
+ *
+ * The directory is the other half of the key, and it is load-bearing:
+ * `src/services/app-secrets-rules.ts` is the app-secrets store's own key/value
+ * shape rules, written long before this convention and belonging to no
+ * configuration surface. The registry's rules modules live where the registry
+ * lives (project intent §Decisions, "Where does the registry live?"), which is
+ * also where a `preflight` handler has to be, so the name means one thing in
+ * one place instead of catching every module in the tree that ends in the same
+ * eight characters.
+ */
+export declare function isRulesModulePath(modulePath: string): boolean;
+/** One string literal of a module: where it sits, and what it says. */
+export interface RuleModuleStringLiteral {
+    /** Index of the opening quote. */
+    start: number;
+    /** Index just past the closing quote. */
+    end: number;
+    /** The literal's raw content — escapes are left as written. */
+    value: string;
+    /** `"`, `'` or a backtick. */
+    quote: string;
+}
+/** A module's masked source plus every string literal the masker blanked. */
+export interface RuleModuleLexis {
+    /** Comments, string contents and regex literals blanked, positions kept. */
+    masked: string;
+    /** The literals, in source order — a blanked `"message"` key is still one. */
+    strings: RuleModuleStringLiteral[];
+}
+/**
+ * Blank out comments, string-literal CONTENTS and regex literals, preserving
+ * every character position and every newline, so a regex over the result
+ * reports the same line numbers as the original and can never match prose, a
+ * quoted example, or a pattern.
+ *
+ * Regex literals are tracked because a perfectly ordinary validation pattern
+ * carries quotes — `/'/`, `/["']/` — and a masker that read that apostrophe as
+ * a string would blank the rest of the module, hiding every `throw` after it.
+ * That is a guard that silently stops looking, which is worse than no guard.
+ * A `/` that opens what turns out not to be a regex (no closing `/` before the
+ * line ends) is treated as division, so the masker never runs away.
+ *
+ * Template literals are scanned with their `${…}` interpolations lexed as code,
+ * so a nested backtick cannot end the literal early either.
+ */
+export declare function lexRuleModuleSource(source: string): RuleModuleLexis;
+/**
+ * The module's source with comments, string contents and regex literals blanked
+ * — the view every structural check reads, positions and line numbers intact.
+ */
+export declare function maskRuleModuleSource(source: string): string;
+/**
+ * Every fault in one surface's rule declaration, each naming the surface and
+ * what is wrong. `[]` means the declaration is well-formed — INCLUDING a
+ * surface that has declared neither slot, which is the unmigrated list's
+ * business (`findUnmigratedListDrift`), not a malformed declaration.
+ */
+export declare function findMalformedRuleDeclarations(surface: ConfigObjectSurface): string[];
+/**
+ * The same rule id declared on two surfaces with DIFFERENT handlers.
+ *
+ * One id naming one handler on two surfaces is deliberate — the signing-secret
+ * rule is one rule the webhook and function objects share — but one id naming
+ * two implementations is the drift this registry exists to end.
+ */
+export declare function findCrossSurfaceRuleIdConflicts(surfaces: readonly ConfigObjectSurface[]): string[];
+/** Declared rule ids per handler module — the declaration side of the anchor. */
+export declare function declaredRuleIdsByModule(surfaces: readonly ConfigObjectSurface[]): Map<string, string[]>;
+/** Every distinct `<module>#<export>` a surface's rules name, sorted. */
+export declare function ruleHandlerReferences(surface: ConfigObjectSurface): string[];
+/**
+ * Read every `export const X_RULE_IDS = [...] as const` out of module SOURCE.
+ *
+ * Static on purpose: an `apply`-stage handler lives in a server module the CLI's
+ * unit test must never import, and the list has to be readable anyway.
+ *
+ * The declaration is walked, not matched against one regex, for two reasons a
+ * guard cares about. A list is found whether or not the statement ends in a
+ * semicolon — under automatic semicolon insertion `…] as const` is the same
+ * declaration, and a module that dropped the semicolon must not drop out of
+ * discovery. And the ids are the module's real STRING LITERALS, so an id that
+ * has been commented out inside the array is not read as one: it is absent from
+ * the runtime list and from the union type, so a declaration still citing it
+ * has to fail.
+ */
+export declare function parseRuleIdExports(source: string): {
+    lists: Array<{
+        name: string;
+        ids: string[];
+    }>;
+    errors: string[];
+};
+/**
+ * Refusals a migrated module builds OUTSIDE its typed constructor (DSO-001).
+ *
+ * The type-level half of the rule-id anchor — a constructor whose id parameter
+ * is the list's union — cannot see `throw new Error("ninth refusal")` or
+ * `errors.push({ message })`: both change no export and no type. This is the
+ * source-level half, and it applies only to a MIGRATED module (one that exports
+ * a `*_RULE_IDS` list), so an unmigrated module is untouched until its sibling
+ * issue migrates it.
+ *
+ * A refusal literal is caught in all three spellings a `message` property has —
+ * `message:`, `"message":` and the `{ ruleId, message }` shorthand — because a
+ * bypass that only had to be quoted differently would not be a guard.
+ */
+export declare function findUnanchoredRefusals(source: string, listName?: string): string[];
+/**
+ * Drift between the rule ids modules EXPORT and the ids surfaces DECLARE, in
+ * both directions. The first direction is the ninth-refusal case: a new id in a
+ * module's list that no surface declares fails until it is declared.
+ */
+export declare function findRuleIdDrift(declared: ReadonlyMap<string, readonly string[]>, exported: ReadonlyMap<string, readonly string[]>): string[];
+/**
+ * Exported rule functions in a registry rules module that no surface claims
+ * (intent §Success criteria 1). A rules module is where rules live; an export
+ * nothing declares is a rule running with no declaration. `[]` for anything
+ * `isRulesModulePath` does not recognize.
+ *
+ * Both spellings of an export count: `export function check()` and a later
+ * `export { check }` clause, alias included — how a rule reaches the module's
+ * surface is a style choice, and a guard that only saw one of the two would be
+ * satisfied by rewriting the other.
+ */
+export declare function findUnclaimedRuleModuleExports(modulePath: string, source: string, claimedExports: readonly string[]): string[];
+/**
+ * Drift between the shrink-only unmigrated inventory and the registry, in both
+ * directions: a listed label that is not a surface, a listed label that has
+ * already declared, a surface that has declared neither slot and is not listed,
+ * and a duplicate entry.
+ */
+export declare function findUnmigratedListDrift(surfaces: readonly ConfigObjectSurface[], unmigrated: readonly string[]): string[];
+/** Whether this surface has declared its cross-field rules either way. */
+export declare function hasDeclaredCrossFieldRules(surface: ConfigObjectSurface): boolean;
+/**
+ * The surface's declared rules for one stage, in declaration order — the
+ * derivation `config push`'s two-stage contract replaces its hand-maintained
+ * ordering with (#3375 is the consumer).
+ *
+ * Throws for a surface that has declared neither slot, rather than returning
+ * `[]`: "not declared yet" must never be read as "has no rules" (principle 6).
+ */
+export declare function crossFieldRulesForStage(surface: ConfigObjectSurface, stage: CrossFieldRuleStage): readonly CrossFieldRule[];
+/**
+ * Is a rule declared `preflight` actually reached before `config push` mutates
+ * anything? (issue #3375, project phase 3, intent §Success criteria 5.)
+ *
+ * #3373 gave a rule a `stage`; #3374 declared three surfaces' rules. Both left
+ * the string a PROMISE. "This runs before the first mutating call" was
+ * satisfied by typing `preflight` beside a rule that is not on the preflight
+ * path at all, because the push preflight was an inline block inside the
+ * command's `.action()` callback with no exported symbol — so "reached from the
+ * preflight" had nothing to resolve against.
+ *
+ * #3375 extracts that block into `cli/src/commands/sync.ts#runConfigPushPreflight`
+ * and this module answers the question statically, from the declared
+ * `<module>#<export>`:
+ *
+ *   - `reachableExports` walks the call graph from one entry symbol over module
+ *     SOURCE TEXT and returns what it reached — plus what it could NOT resolve,
+ *     so silence is never a pass.
+ *   - `findUnreachedPreflightRules` reports every `preflight` declaration,
+ *     cross-field or single-field, whose handler is missing from that set.
+ *   - `findMalformedFieldValidationStages` is the field-level twin of #3373's
+ *     `findMalformedRuleDeclarations`: `ConfigField["validation"]` gained a
+ *     `stage` here, and it must be well-formed to mean anything.
+ *
+ * Everything is a PURE function over values and over source text the caller
+ * passes in: `cli/tests/unit/config-surface-preflight-staging-3375.test.ts`
+ * does the filesystem walk, so this module stays vendorable (`types.ts`
+ * §Purity), exactly the split `rules.ts` already uses.
+ *
+ * ── Two things this check is NOT ──────────────────────────────────────────
+ *
+ * It is NECESSARY, not sufficient, and there is deliberately no converse. A
+ * handler reached on one surface's leg satisfies a `preflight` declaration on
+ * another (the residual the intent accepts and #3379 records), and asking "is
+ * this `apply` rule reached from the preflight?" would be wrong by
+ * construction: `validateSigningSecretDeclaration` IS reached on the function
+ * leg and IS correctly `apply` on the webhook surface, where no CLI call
+ * exists.
+ *
+ * The walk is identifier-based over masked source, so it over-approximates in
+ * the PASSING direction: a local variable shadowing an imported handler's name
+ * reads as a call. That is the safe direction for a guard whose failure mode
+ * must be "a promise you did not keep", not "a promise you did keep, reported
+ * as broken".
+ */
+/** A field's `validation` object may carry these keys and no others (#3375). */
+export declare const FIELD_VALIDATION_KEYS: readonly string[];
+/**
+ * The modules a walk may read, and how a specifier resolves between them.
+ *
+ * The caller owns resolution because it owns the filesystem: the CLI test maps
+ * both spellings of the vendored artifact onto the `src/config-surface/`
+ * modules it is a copy of, which is the whole point of DSO-3375-002 — the
+ * generator strips every intra-directory import before concatenating, so the
+ * artifact itself carries no edges between its sections.
+ */
+export interface StaticModuleGraph {
+    /** Repo-relative module path → that module's SOURCE TEXT. */
+    modules: ReadonlyMap<string, string>;
+    /**
+     * Candidate modules a specifier names, seen from `fromModule`.
+     *
+     * `null` = a bare package specifier: deliberately not followed, and never
+     * reported. `[]` = a relative specifier that resolves to no module in the
+     * graph, which IS reported — a guard that silently stops looking is worse
+     * than no guard.
+     */
+    resolve(fromModule: string, specifier: string): readonly string[] | null;
+}
+/** What one walk found, and what it could not resolve on the way. */
+export interface ReachabilityWalk {
+    /** `<module>#<export>` for every symbol reached, module = where it is DECLARED. */
+    reached: ReadonlySet<string>;
+    /** Specifiers and entry symbols the graph could not answer for, sorted. */
+    unresolved: string[];
+}
+/**
+ * Walk the call graph from `entry` and return every symbol it reaches.
+ *
+ * An identifier inside a reached declaration's span is followed when it names
+ * another top-level declaration of the same module, or a value import — which
+ * resolves through the graph to whichever candidate module DECLARES the name,
+ * following `export { x } from` and `export * from` on the way. A symbol is
+ * recorded under the module that declares it, never under a barrel that merely
+ * re-exports it: a declaration that names the barrel is reported unreached,
+ * because the point of the string is to name the one implementation.
+ */
+export declare function reachableExports(entry: string, graph: StaticModuleGraph): ReachabilityWalk;
+/**
+ * Every fault in one surface's FIELD validation declarations, each naming the
+ * surface and the field. `[]` means every field is well-formed.
+ *
+ * Runs over every surface in the registry, migrated or not: field declarations
+ * exist independently of the cross-field slot, so the
+ * `CROSS_FIELD_RULES_UNMIGRATED` ratchet does not — and must not — stand
+ * between a field-level `preflight` declaration and this check (DSO-3375-001).
+ */
+export declare function findMalformedFieldValidationStages(surface: ConfigObjectSurface): string[];
+/**
+ * Every `preflight` declaration on this surface whose handler the walk did not
+ * reach, each naming the surface, the rule (or field), the handler and the
+ * entry point.
+ *
+ * The FIELD half runs on every surface. The CROSS-FIELD half runs only where a
+ * surface has declared, because `crossFieldRulesForStage` throws for one that
+ * has not — "not declared yet" is never "rule-free" (#3373), and asking it
+ * here would turn an unmigrated surface into a crash rather than a skip.
+ */
+export declare function findUnreachedPreflightRules(surface: ConfigObjectSurface, reached: ReadonlySet<string>, entry: string): string[];
+/**
+ * Request schemas generated from the configuration-object definitions
+ * (issue #2644, phase 5 / criterion 9).
+ *
+ * Every create/update handler in this family used to drop, in silence, any body
+ * key it did not read. A client sending `timoutMs` for `timeoutMs` got a 200 and
+ * no timeout change. These schemas close that: one per object and mode,
+ * `additionalProperties: false`, properties = the keys that object accepts on
+ * the wire in that mode, so an unknown key is a 400 naming it.
+ *
+ * **Breaking change, named**: a client that sends a stray key and gets a 200
+ * today will get a 400. The CLI never hits it — `config push` already rejects
+ * unrecognized TOML keys locally (criterion 6).
+ *
+ * ── What the schema says, and what it deliberately does not ──────────────
+ * It states the KEY SET only: each property is the empty schema (or carries
+ * only the `deprecated` annotation, #1815), so no value is type-checked here. That is the decision of record (#1976, carried forward at
+ * #2644's design gate): the definition classifies, handlers behave. The
+ * `status` enum, the queue limits' integer coercion, `runAs`'s caller|system
+ * check, the CEL parse of `accessRule` — all stay in the handlers the
+ * definition names, with their existing messages. Adding type gates here would
+ * duplicate them and start rejecting values the handlers accept.
+ *
+ * ── Which keys are in the set ────────────────────────────────────────────
+ * Derived, not listed:
+ *
+ *   - every field the definition says is writable in this mode;
+ *   - every field classified `structural` — the authored sub-trees that travel
+ *     on their own channel (`rules`, `steps`, `metadataManifest`, `schema`,
+ *     `triggers`) but are still sent in the body — in the modes that entry
+ *     declares (`requestModes`; omitted means both, `[]` means the key travels
+ *     in the URL path and no schema admits it);
+ *   - every field classified `deprecated` — still writable server-side, by
+ *     definition of that classification;
+ *   - the table's `requestOnlyKeys`, in the modes each declares: protocol keys
+ *     that are not model fields at all, such as the `expectedModifiedAt`
+ *     optimistic-concurrency token or a create-only alias.
+ *
+ * `server-owned` and `secret` classifications are the two the schema excludes:
+ * the first is assigned by the server, the second never travels in readable
+ * form.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ */
+/**
+ * A generated request schema. Shaped for the app API's `meta.request` slot and
+ * the runtime validator it feeds (`src/app-api/request-validation.ts`), which
+ * reports an unknown key as `value.<key> is not allowed`.
+ */
+export interface ConfigRequestSchema {
+    type: "object";
+    /**
+     * Each property is the empty schema, or `{ deprecated: true }` for a field
+     * the definition marks `deprecated` (#1815). `deprecated` is an OpenAPI
+     * annotation: it constrains no value, so the schema still states the key set
+     * and nothing more.
+     */
+    properties: Record<string, {
+        deprecated?: true;
+    }>;
+    additionalProperties: false;
+    /**
+     * Structural-typing escape hatch: the app API's `meta.request` slot is a
+     * `Record<string, unknown>` (`JsonSchema`), and an interface with no index
+     * signature is not assignable to one. Declaring the index here keeps the
+     * generated schema usable as a route schema without an `as any` at every
+     * call site.
+     */
+    [key: string]: unknown;
+}
+/**
+ * Protocol keys every config UPDATE accepts, whichever object it is.
+ *
+ * `expectedModifiedAt` is the optimistic-concurrency token `config push` attaches
+ * to an update body when it has a baseline from the last pull; a handler that
+ * does not implement conflict detection ignores it. It is a property of the
+ * sync protocol rather than of any one object, which is why it is stated once
+ * here instead of in thirteen definitions.
+ */
+export declare const UPDATE_PROTOCOL_KEYS: readonly string[];
+/** The body keys this table accepts in `mode`, in a stable order. */
+export declare function requestSchemaKeys(table: ConfigTable, mode: "create" | "update"): string[];
+/**
+ * The request schema for one object and mode. Generated from the definition, so
+ * a schema permitting a key the definition does not is unrepresentable: there
+ * is no place to write one.
+ */
+export declare function configRequestSchema(table: ConfigTable, mode: "create" | "update"): ConfigRequestSchema;
+/**
+ * The retired-key guidance for a generated schema, keyed by body key — or
+ * `undefined` when the schema's object has none. Consumed by the app API's
+ * request validator (`src/app-api/request-validation.ts`).
+ */
+export declare function retiredRequestKeys(schema: object | undefined): Readonly<Record<string, string>> | undefined;
+/**
+ * One schema for an endpoint whose body spans MORE than one table.
+ *
+ * `POST …/prompts` is the case: it creates the prompt AND seeds its first
+ * config, so the body carries `[prompt]` fields and `[[configs]]` fields
+ * together. Both halves still come from their definitions — this only says the
+ * endpoint accepts the union, in the one place that is true.
+ */
+export declare function mergeRequestSchemas(...schemas: readonly ConfigRequestSchema[]): ConfigRequestSchema;
+/**
+ * The body keys `table` does not accept in `mode` — the 400's subject.
+ *
+ * Used by the admin API, which has no request-schema middleware: its handlers
+ * call this directly so both APIs reject the same key set for the same object.
+ */
+export declare function unknownRequestKeys(body: unknown, table: ConfigTable, mode: "create" | "update"): string[];
+/** The 400 message naming the unknown key(s), shared by both APIs. */
+export declare function unknownRequestKeysMessage(keys: readonly string[]): string;
+/**
+ * Keys deliberately RETIRED from a configuration object's write surface.
+ *
+ * A retired key is not an unknown key. The generic hint for an unrecognized
+ * TOML key — "check the spelling, or upgrade the CLI" — is exactly backwards
+ * for one this CLI removed on purpose, and the generic 400 for an unaccepted
+ * request key says only that the key is not allowed, not where the value moved
+ * to. Both surfaces need the same sentence, and neither should invent it.
+ *
+ * So the guidance lives here, next to the definitions, with one entry per
+ * retired key: the TOML wording for `config push` (which can tell the author to
+ * delete a line) and the request wording for the API handlers (which cannot).
+ *
+ * Keyed by the table's TOML path prefix (`workflow`, `cronTrigger`, …), because
+ * that is the identifier both consumers already have in hand.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ */
+export interface RetiredConfigKey {
+    /** What `config push` says about a file that still carries the key. */
+    toml: string;
+    /** What a create/update handler says about a body that still sends it. */
+    request: string;
+}
+export declare const RETIRED_CONFIG_KEYS: Record<string, Record<string, RetiredConfigKey>>;
+/** The retired-key entry for `key` under `prefix`, or null when it is simply unknown. */
+export declare function retiredConfigKey(prefix: string, key: string): RetiredConfigKey | null;
+/**
+ * The capability grammar for server functions — #3182 phase 1, rewritten by
+ * #3279 (project `server-functions` phase 3).
+ *
+ * A function declares in its own TOML what it may CONFIGURE:
+ *
+ *   capabilities = ["integration:stripe", "secret:STRIPE_KEY", "databases:delete"]
+ *
+ * ── Why the grammar is this small ────────────────────────────────────────
+ *
+ * The intent's decision (2026-09-09, "Authorization inside a function?"):
+ * function code acts as the system. The invocation gate is the authorization,
+ * and inside a function every platform call carries the app's own authority in
+ * every family. A capability is therefore never a statement about DATA — a
+ * model, a prompt, a channel, a member — because the function may reach all of
+ * it. It is declared only where it configures something:
+ *
+ *   `integration:<key>`   the egress allowlist — which upstream hosts the
+ *                         function's outbound calls may reach;
+ *   `secret:<NAME>`       credential least privilege — which secret VALUES may
+ *                         cross into the sandbox at all;
+ *   the high-blast list   {@link HIGH_BLAST_CAPABILITIES} — the operations
+ *                         whose blast radius the intent keeps opt-in.
+ *
+ * Every other string a function used to declare is RETIRED, and the grammar
+ * says so by name: an author who still writes `database:orders/Order:read`
+ * is told the model changed and what stays, not "unknown family", which would
+ * send them to check their spelling.
+ *
+ * ── Why the components have a charset ────────────────────────────────────
+ *
+ * A keyed grant's key must match `[A-Za-z0-9_-]+`, so neither `:` nor `/` can
+ * enter a component and the string is INJECTIVE — one string, one object. An
+ * integration or secret whose key carries a delimiter is simply unreachable
+ * from functions, with an error that says why (D3182-001's argument, kept).
+ *
+ * ── Why this module is pure ──────────────────────────────────────────────
+ *
+ * Capabilities are validated twice — by `config push`'s preflight, so an
+ * author sees the error against their own file, and by the server, which is
+ * authoritative because the raw admin API exists. Two enforcement points must
+ * not be two grammars, so the grammar lives here, in the dependency-free
+ * `src/config-surface/` tree the CLI vendors at build time
+ * (`cli/scripts/gen-config-surfaces.mjs`). The server imports this module; the
+ * CLI imports the generated copy; the drift guard fails if they differ.
+ */
+/** Every component of a grant. Injectivity depends on this. */
+export declare const GRANT_COMPONENT_PATTERN: RegExp;
+/** `ServerFunctionConfig.capabilities` is a StringSet with these bounds. */
+export declare const MAX_CAPABILITY_ENTRIES = 100;
+export declare const MAX_CAPABILITY_ENTRY_LENGTH = 200;
+/**
+ * The two keyed families the intent keeps: one component under
+ * {@link GRANT_COMPONENT_PATTERN}, naming a single object. Every key format the
+ * platform issues fits: an integration key is `^[a-z0-9][a-z0-9-_]{2,}$` and a
+ * secret name is `^[A-Z][A-Z0-9_]{0,63}$`.
+ */
+export declare const KEYED_GRANT_FAMILIES: readonly ["integration", "secret"];
+/**
+ * The high-blast-radius opt-ins — #3279, criterion 5 (CR3279-001, D3279-003).
+ *
+ * Since function code acts as the system, admission to a family is no longer
+ * an authority statement: everything the gateway lets through runs with the
+ * app's own authority. Most operations are fine that way — that is the whole
+ * decision. A short list is not, and the intent names its categories: delete a
+ * database, app or user; role changes; secret changes; resource provisioning.
+ * Those stay opt-in, so a function that can do them says so in a reviewable
+ * line of its TOML.
+ *
+ * The strings are EXACT and 1:1 with the operation id, so there is nothing to
+ * look up: `users.setRole` needs `users:setRole`. They parse with the verb as
+ * their KEY, because two exact capabilities in one family must not cover each
+ * other — `databases:create` is not permission to delete a database.
+ *
+ * The database ROLE mutations are here because they hand out persistent
+ * authority: a group grant assigns the manager role (D3279-003). App deletion
+ * and secret writes have no app-API route today; they are recorded, not gated,
+ * and the profile generator refuses to admit a future such route without a row
+ * here (`HIGH_BLAST_WATCH` in `scripts/lib/function-profile.mjs`).
+ */
+export declare const HIGH_BLAST_CAPABILITIES: readonly ["databases:create", "databases:delete", "databases:transferOwnership", "databases:addManager", "databases:revokePermission", "databases:grantGroupPermission", "databases:revokeGroupPermission", "users:remove", "users:setRole", "blobBuckets:createBucket", "blobBuckets:deleteBucket"];
+/** The exact strings, which since #3279 are exactly the high-blast list. */
+export declare const EXACT_GRANT_STRINGS: readonly ["databases:create", "databases:delete", "databases:transferOwnership", "databases:addManager", "databases:revokePermission", "databases:grantGroupPermission", "databases:revokeGroupPermission", "users:remove", "users:setRole", "blobBuckets:createBucket", "blobBuckets:deleteBucket"];
+export type GrantFamily = (typeof KEYED_GRANT_FAMILIES)[number] | "databases" | "users" | "blobBuckets";
+/**
+ * The retired FAMILIES (#3279), each with the reason it is gone.
+ *
+ * The value is what the family used to authorize, phrased as what a function
+ * now reaches without it. A refusal names the authored string, says it is
+ * retired, gives this reason, tells the author to delete the entry, and lists
+ * what stays.
+ */
+export declare const RETIRED_GRANT_FAMILIES: Record<string, string>;
+/** The retired EXACT strings (#3279), on the same terms. */
+export declare const RETIRED_GRANT_STRINGS: Record<string, string>;
+/**
+ * The retirement sentence for one authored string, or null when the string is
+ * not a retired one.
+ *
+ * Exported so the enforcement-time reader (`loadConfigGrants`) can tell a
+ * retired string on a pre-change row — tolerated, logged — from a string that
+ * was never a grant at all, which still authorizes nothing.
+ */
+export declare function retiredGrantRefusal(raw: string): string | null;
+/**
+ * Any grant, in one flat shape.
+ *
+ * Flat rather than a discriminated union because this module is vendored into
+ * the CLI, which compiles with `strict: false`: a caller reads `family` and
+ * then `key`, and the fields another family would have used are simply absent.
+ */
+export interface FunctionGrant {
+    family: GrantFamily;
+    /**
+     * The single component of a keyed family — the integration key or the
+     * secret name — or the VERB of a high-blast string (`delete` for
+     * `databases:delete`), so that no two exact capabilities in one family read
+     * as the same grant.
+     */
+    key: string;
+    /** The authored string, so an error or a log line can quote it. */
+    raw: string;
+}
+export interface ParsedFunctionGrant {
+    grant?: FunctionGrant;
+    error?: string;
+}
+/**
+ * A channel name's ceiling, and the reason it has one.
+ *
+ * The name rides in a `ConnectionMapping` row's document-id slot as
+ * `ch:<appId>:<channel>` and in every grant token's claims, so an unbounded
+ * name would be an unbounded key and an unbounded credential. 200 characters
+ * is {@link MAX_CAPABILITY_ENTRY_LENGTH}, kept for continuity with the rows
+ * #3184 already wrote.
+ */
+export declare const MAX_CHANNEL_NAME_LENGTH = 200;
+export interface ParsedChannelName {
+    /** The segment before the first `:`. Absent when the name is refused. */
+    namespace?: string;
+    error?: string;
+}
+/**
+ * A channel NAME, and its namespace.
+ *
+ * The grammar is the grant component charset applied per segment: one or more
+ * `[A-Za-z0-9_-]+` segments joined by `:`. The `channel:<namespace>` GRANT
+ * that used to cover a name is retired (#3279); the name grammar stays because
+ * the authorize and publish routes answer 400 about a name outside it before
+ * anything else, and the connection worker keys membership by it.
+ *
+ * Refusals name the segment that failed, because "channel name is invalid" on
+ * a name like `orders:a::b` tells an author nothing they cannot already see.
+ */
+export declare function parseChannelName(value: unknown): ParsedChannelName;
+/**
+ * One capability entry as a grant, or the reason it is not one.
+ *
+ * The single entry point the enforcement path and both preflights use: a
+ * caller holds one authored string and asks what it grants, without having to
+ * know which of the shapes to try. Every diagnosis is specific — a retired
+ * string gets the retirement and what stays; a near miss in a kept family gets
+ * the family's own strings; a keyed family gets its charset rule.
+ */
+export declare function parseFunctionGrant(entry: unknown): ParsedFunctionGrant;
+/**
+ * One shape rather than a discriminated union: this module is vendored into
+ * the CLI, which compiles with `strict: false`, where narrowing on a boolean
+ * literal discriminant does not hold. Both callers read `ok` and then the
+ * field they want, and the unused half is empty rather than absent.
+ */
+export interface ParsedCapabilities {
+    ok: boolean;
+    /** Deduped, in authored order — what the config row stores. Empty when refused. */
+    capabilities: string[];
+    /** Every grant, in authored order. */
+    allGrants: FunctionGrant[];
+    /**
+     * The retired strings that were SKIPPED, in authored order — populated only
+     * under `tolerateRetired` (see {@link parseCapabilities}); a strict parse
+     * refuses them instead and leaves this empty.
+     */
+    retired: string[];
+    /** Empty when accepted. */
+    errors: string[];
+}
+export interface ParseCapabilitiesOptions {
+    /**
+     * Skip retired strings instead of refusing them — #3279 edge 25.
+     *
+     * The PUSH path is strict: a file that still declares a retired grant is
+     * refused with the retirement, because a line that is accepted and ignored
+     * is a line the author believes means something. The ENFORCEMENT path is
+     * tolerant: a config version pushed before #3279 carries retired strings in
+     * a row that can never be re-pushed to fix (its envelope is immutable), and
+     * refusing it there would break every function pushed before the change.
+     * Such a row authorizes exactly what it keeps, and the skipped strings are
+     * reported in `retired` so the caller can log them.
+     */
+    tolerateRetired?: boolean;
+}
+/**
+ * A whole `capabilities` list: shape, bounds, grammar, duplicates.
+ *
+ * The model's own caps are checked HERE rather than left to the StringSet
+ * field, so an over-long entry is a named push error instead of a late model
+ * throw after the R2 object has already been written (principle 6).
+ */
+export declare function parseCapabilities(value: unknown, options?: ParseCapabilitiesOptions): ParsedCapabilities;
+/**
+ * The config-tree objects an `integration:` grant may name.
+ *
+ * Only the one family whose target is CONFIG-TREE state. `secret:` is absent
+ * on purpose (D3183-002): its values are provisioned per environment, out of
+ * band, and are not part of the reviewed tree at all, so the ordinary order of
+ * work is to push the function and then provision the value. Refusing an
+ * unprovisioned name at push would break that; a missing value at CALL time is
+ * a structured runtime error instead. The high-blast strings name no object.
+ *
+ * `null` means "this enforcement point could not find out". The CLI reads the
+ * tree and, when it can, a live listing; when neither is available it defers
+ * rather than guessing, because a preflight that refused a valid tree for
+ * being offline would be worse than one that lets the server have the last
+ * word. The server never passes null — it can always read its own rows.
+ */
+export interface KnownGrantTargets {
+    /** Non-archived integration keys, or null when unknown. */
+    integrations: ReadonlySet<string> | null;
+}
+/**
+ * Grants naming an integration the app does not have.
+ *
+ * One message per offending grant, quoting the whole authored string AND the
+ * key on its own, so an operator reading the line knows both what to fix in
+ * the file and what to create in the app.
+ *
+ * The rule is here, beside the grammar, for the reason the whole module
+ * exists: `config push`'s preflight and the authoritative server check read
+ * different sources for the same facts — a `.toml` in the tree versus a row
+ * in DynamoDB — and it is the RULE that must not differ between them.
+ */
+export declare function validateKeyedGrantsAgainstTargets(grants: readonly FunctionGrant[], known: KnownGrantTargets): string[];
+/**
+ * The query manifest's grammar, and the read rule it unlocks — #3187, project
+ * `server-functions` phase 5.
+ *
+ * A pushed config version may carry a MANIFEST: the queries and mutations the
+ * tree registered at module scope, collected by the CLI (`function-collect.ts`)
+ * by running the tree with `primitive-functions` aliased to a recording stub.
+ *
+ * ── What the manifest is for ─────────────────────────────────────────────
+ *
+ * Observability, and nothing else. `primitive functions get` and the admin
+ * get list what a version registered, so an operator can see it without
+ * reading the bundle (principle 8). The read rule it used to be decided from
+ * (#3187's `$caller` relaxation of `unscopedReads`) is retired by #3279:
+ * function code acts as the system, so there is no per-model grant for a
+ * binding to waive. The intent says so in as many words — "the models a
+ * function touches are collected at push as a reviewable manifest, not an
+ * authorization".
+ *
+ * It is HONEST-CODE evidence and the design doc says so: a hostile bundle can
+ * register whatever it likes, because the collector runs the tenant's own
+ * code. Nothing security-relevant at runtime reads it — parameter injection
+ * and cache verification happen in the platform-owned SDK inside the isolate,
+ * and the invocation gate remains the adversarial boundary.
+ *
+ * ── Why the grammar is here ──────────────────────────────────────────────
+ *
+ * Same reason as `function-grants.ts`: the CLI validates at push preflight so
+ * an author sees the error against their own tree, and the server validates
+ * authoritatively because the raw admin API exists. Two enforcement points,
+ * one rule, in the dependency-free tree the CLI vendors.
+ */
+/**
+ * The manifest encoding, versioned with the envelope that carries it.
+ *
+ * Version 2 (#3279 behavior 10) adds what a function TOUCHES beside what it
+ * registers: the deduplicated `models` its code names and the `families` of
+ * `ctx.api` and the ctx helpers it reaches, collected by a static scan of the
+ * built bundle, plus a `dynamicModels` marker for a model name the scan
+ * could not resolve — distinct from an empty list, which means "names none".
+ * A version-1 manifest still parses: it records registrations only.
+ */
+export declare const FUNCTION_MANIFEST_SCHEMA_VERSION = 2;
+export declare const FUNCTION_MANIFEST_SCHEMA_VERSIONS: readonly [1, 2];
+/** Bounds, so a manifest cannot be a way to store an unbounded blob. */
+export declare const MAX_MANIFEST_QUERIES = 200;
+export declare const MAX_MANIFEST_NAME_LENGTH = 120;
+export declare const MAX_MANIFEST_MODELS = 200;
+export declare const MAX_MANIFEST_FAMILIES = 40;
+export interface ManifestParam {
+    type?: string;
+    /** `type: "array"` — the element type, when declared (#3281). */
+    items?: {
+        type: string;
+    };
+    caller?: boolean;
+    optional?: boolean;
+    default?: unknown;
+}
+/** The scalar parameter types a registration may declare, and an array's element types. */
+export declare const QUERY_PARAM_SCALAR_TYPES: readonly ["string", "number", "boolean", "any"];
+/**
+ * Coerce one value to a declared parameter type the way the SDK coerces a
+ * SUPPLIED value: a digit string becomes a number, `"true"`/`"false"` a
+ * boolean, an array's elements each by the `items` type. Applied to a
+ * declared `default` at registration (D3281-SO-005) so what `run` receives is
+ * what the declaration promises — here at push (the collect stub and this
+ * grammar) and in the SDK at the first load. ONE rule, spelled in the SDK's
+ * source a second time because that module is baked text; the tests hold the
+ * two together.
+ */
+export declare function coerceParamDefault(spec: {
+    type?: string;
+    items?: {
+        type?: string;
+    };
+}, value: unknown): {
+    ok: true;
+    value: unknown;
+} | {
+    ok: false;
+    reason: string;
+};
+export interface ManifestQuery {
+    name: string;
+    kind: "query" | "mutation";
+    models: string[];
+    params: Record<string, ManifestParam>;
+    cache: {
+        ttlMs: number;
+    } | null;
+    /** True when a `$caller` binding scopes this registration. */
+    callerScoped: boolean;
+}
+export interface FunctionManifest {
+    schemaVersion: number;
+    queries: ManifestQuery[];
+    /**
+     * Every model name the bundle names, deduplicated and sorted: registration
+     * declarations, literal `.model("…")` calls, and literal `modelName`/`model`
+     * arguments of the direct records and documents calls (#3279). Empty for a
+     * version-1 manifest, and for a function that names none.
+     */
+    models: string[];
+    /** Every `ctx.api.<family>` and ctx-helper family the bundle reaches. */
+    families: string[];
+    /**
+     * The scan met a model name it could not resolve — a computed
+     * `modelName`, a `.model(variable)`. Says "and possibly more", which an
+     * empty `models` list does not.
+     */
+    dynamicModels: boolean;
+}
+export interface ParsedManifest {
+    ok: boolean;
+    manifest: FunctionManifest | null;
+    errors: string[];
+}
+/**
+ * Validate a manifest's grammar and normalize it.
+ *
+ * Deliberately strict about SHAPE and silent about meaning: whether the models
+ * exist, whether the queries are the ones the sandbox will really register,
+ * and whether the author meant any of it are questions this cannot answer.
+ */
+export declare function parseFunctionManifest(value: unknown): ParsedManifest;
+/**
+ * The runtime keys a `functions/<key>.toml` no longer decides anything with —
+ * #3482, project `server-functions` phase 4.
+ *
+ * The sponsor settled it on 2026-09-15 (the intent, "Mode vocabulary?",
+ * amended again): the config says NOTHING about how a function runs. A
+ * function is a function; the caller picks the runtime at each call, cron
+ * fires always start a task run, webhook deliveries always run as a request,
+ * and a function that must not run under one runtime tests for it in code with
+ * `assertRuntime`.
+ *
+ * ── Why these keys are accepted, not refused ──────────────────────────────
+ *
+ * Every tree pushed since #3454 that declares a cron trigger carries
+ * `mode = …` ON THE ENTRY, because `cron-trigger-mode-required` demanded it;
+ * plenty carry a top-level `mode` or the older `durable`. Removing the keys
+ * from the accepted set outright would refuse those trees with an unknown-key
+ * error one day after the platform insisted on them, which is the opposite of
+ * principle 5 inside a non-breaking phase.
+ *
+ * So through phase 4 they are ACCEPTED and IGNORED, with one warning per key
+ * naming it and the line to delete; from phase 5 (#3188) they are refused with
+ * the rest of the retirement matrix. The value is not validated — there is
+ * nothing left to validate it against, and refusing a bad value for a key
+ * nobody reads would be a refusal about spelling alone.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity). Both
+ * the CLI preflight (vendored by `cli/scripts/gen-config-surfaces.mjs`) and the
+ * admin config-version route read this one scanner, so the warning an author
+ * sees from `config push` is the sentence the API answers with.
+ */
+/** The two `[function]` keys that no longer say anything (#3482). */
+export declare const RETIRED_FUNCTION_RUNTIME_KEYS: readonly ["mode", "durable"];
+export type RetiredFunctionRuntimeKey = (typeof RETIRED_FUNCTION_RUNTIME_KEYS)[number];
+/** One ignored key met in a `[function]` table. */
+export interface IgnoredFunctionKey {
+    /**
+     * Where it was: `mode`, `durable`, or `triggers.cron.<name>.mode`. Never
+     * rendered on its own — a reader that wants to branch reads this, and every
+     * printer reads `message`.
+     */
+    path: string;
+    /** The sentence the author is owed, with no file prefix (the caller adds it). */
+    message: string;
+}
+/**
+ * Every retired runtime key a `[function]` table still carries.
+ *
+ * Reads the table the way the author wrote it: the two top-level keys, and a
+ * `mode` on each `[[function.triggers.cron]]` entry. A cron entry's sentence
+ * says the extra thing its author needs to hear — that the schedule no longer
+ * chooses, because every fire starts a task run (#3334's runner branch is
+ * gone).
+ *
+ * Order is the order an author reads their file in: the top-level keys first,
+ * then the cron entries in declaration order.
+ */
+export declare function ignoredFunctionKeys(functionTable: unknown): IgnoredFunctionKey[];
+/**
+ * The database types a `[function]` table's retired trigger block names —
+ * #3483.
+ *
+ * Beside `ignoredFunctionKeys` because it answers the same question about the
+ * same table, for the same reader: `config pull` writes a version's AUTHORED
+ * bytes, and a version pushed before the removal carries the block. Without
+ * this the pulled tree would be refused on its next push — a tree an author
+ * cannot get back into a working state, which is the failure D3482-007 already
+ * had to close for the runtime keys.
+ *
+ * This is NOT a refusal and shares nothing with one. The block is refused on
+ * input by `normalizeTriggerDeclaration`; what a strip needs is the list of
+ * entries it is taking out so it can say so, which is why an entry whose
+ * `type` is unreadable still counts as one entry (the empty string). It is the
+ * block's PRESENCE that goes, not its contents.
+ *
+ * TOML spells the block three ways — an array of tables, a single table, and
+ * an inline array — and a scan that missed one would leave a key behind
+ * (CR3482-002's lesson, applied to a whole table).
+ */
+export declare function retiredDatabaseTriggerTypes(functionTable: unknown): string[];
+/**
+ * Whether the block is THERE at all — the question a strip has to ask, which
+ * the type list above cannot answer (CR3483-001).
+ *
+ * `database = []` names no type, so the list is empty and a strip that decided
+ * by its length left the key in the pulled file. That file then fails its own
+ * next push: `normalizeTriggerDeclaration` refuses the key by PRESENCE, of any
+ * shape, an empty array included — so the two halves disagreed about what the
+ * block is, and the tree an author pulled was a tree they could not push.
+ * Presence is the one rule both sides read now, spelled the way
+ * `normalizeTriggerDeclaration` spells it — `!== undefined` — so a value one
+ * of them would call a block and the other would not cannot exist.
+ */
+export declare function hasRetiredDatabaseTriggerBlock(functionTable: unknown): boolean;
+/**
+ * The same scan, rendered for one file — the shape `config push` and
+ * `config diff` print and the admin route answers with.
+ *
+ * `label` is what the reader can act on: `functions/<key>.toml` from the CLI,
+ * and the function's key from the API, which has no file to name.
+ */
+export declare function ignoredFunctionKeyWarnings(label: string, functionTable: unknown): string[];
+/**
+ * The trigger blocks a function declares, derived from its authored TOML
+ * (#3181, project `server-functions`, criterion 4).
+ *
+ * ── The declaration is derived, never supplied ────────────────────────────
+ *
+ * A config-version push carries the authored `functions/<key>.toml` bytes
+ * inside its envelope, and `envelopeHash` covers them. If the push ALSO
+ * carried a parsed `triggers` payload, the two could disagree: a direct API
+ * caller could ship a public webhook trigger the authored file does not
+ * declare, and two pushes with identical envelopes but different trigger
+ * payloads would collapse to one version. So the server parses the envelope's
+ * own bytes here (D3181-005) and there is no payload field to disagree with —
+ * trigger behavior is bound to the version's identity by construction.
+ *
+ * ── Shape only ────────────────────────────────────────────────────────────
+ *
+ * This module decides what the file SAYS: the accepted key set, the required
+ * values, and the rules that need nothing but the document (scheme `none`,
+ * a nameless or duplicated cron entry, an entry count past the per-function
+ * cap, a webhook or database block on a task version). Everything that needs the
+ * app's state — whether a referenced secret exists, whether the
+ * scheme-specific config is valid, whether the app is at its webhook or cron
+ * cap, whether a standalone webhook holds the key — belongs to the push
+ * boundary, which runs the SAME validators the standalone create runs
+ * (D3181-006).
+ *
+ * ── One implementation, two readers (#3320) ───────────────────────────────
+ *
+ * The CLI checks the same rules against the author's own file before a request
+ * is made. It used to do that from a hand-written restatement
+ * (`cli/src/lib/function-triggers.ts`), kept in step only by a paired-fixture
+ * test — so a rule added here with no fixture drifted silently. The rules
+ * therefore live in `src/config-surface/`, which `cli/scripts/
+ * gen-config-surfaces.mjs` vendors verbatim into the committed artifact
+ * `cli/src/lib/generated-config-surfaces.ts`. There is one implementation, and
+ * a change here that is not regenerated fails `--check` (a build failure)
+ * rather than a fixture list that happens not to cover it.
+ *
+ * Reading the authored BYTES is the one thing that stayed server-side:
+ * `deriveTriggerDeclaration` in `src/server-functions/trigger-declaration.ts`
+ * parses them and calls `normalizeTriggerDeclaration` here. This directory
+ * imports nothing but itself (asserted by `config-surface-drift-guard.test.ts`),
+ * and the CLI has already parsed its own file by the time it asks.
+ */
+/**
+ * Why a webhook trigger is the request runtime, and a cron fire a task run —
+ * #3482, the intent's "Mode vocabulary?" decision of 2026-09-15.
+ *
+ * Neither is a rule about the FUNCTION any more, so neither is a refusal: a
+ * function is a function, and the DOOR decides which runtime runs it. A
+ * webhook delivery runs inside the receiver because the provider is holding
+ * the connection open waiting for an answer; a cron fire starts a task run
+ * because it is waiting for nothing. A function that must not run under one of
+ * them tests for it in code with `assertRuntime`, which is the only lock left.
+ *
+ * What survives here is the SHAPE of a declaration — the keys, the names, the
+ * cron expression, the caps. The retired `mode` keys are accepted and reported
+ * as ignored by `ignoredFunctionKeys` in `function-retired-keys.ts`.
+ */
+/** A function's single webhook trigger, normalized. */
+export interface WebhookTriggerDeclaration {
+    verificationScheme: string;
+    signingSecret?: string;
+    toleranceSeconds?: number;
+    deduplicationEnabled?: boolean;
+    deduplicationWindowMs?: number;
+    maxBodyBytes?: number;
+    secretGracePeriodMs?: number;
+    /** `[function.triggers.webhook.verification]` — the row's `config`. */
+    verification?: Record<string, unknown>;
+}
+/** One `[[function.triggers.cron]]` entry, normalized. */
+export interface CronTriggerDeclaration {
+    name: string;
+    cron: string;
+    timezone?: string;
+    overlapPolicy?: string;
+    rootInput?: unknown;
+}
+export interface TriggerDeclaration {
+    webhook: WebhookTriggerDeclaration | null;
+    cron: CronTriggerDeclaration[];
+}
+export declare const EMPTY_TRIGGER_DECLARATION: TriggerDeclaration;
+/**
+ * The most cron entries one function may declare.
+ *
+ * The per-app cap (50) is a resource ceiling; this is a per-OBJECT one, so a
+ * single function cannot take most of an app's budget by itself. Ten is the
+ * same order as the schedules a real function needs and leaves the app's
+ * remaining slots for the other 40+ objects the cap is sized for.
+ */
+export declare const MAX_CRON_TRIGGERS_PER_FUNCTION = 10;
+/**
+ * The rule ids this module owns — one per refusal, declared on the `function`
+ * surface (#3374). The union below closes `refuseTrigger`'s id parameter, so a
+ * twenty-seventh refusal cannot compile without a twenty-seventh id, and that
+ * id fails `cli-unit-tests` until the surface declares it (#3373's anchor).
+ */
+export declare const TRIGGER_RULE_IDS: readonly ["triggers-table", "trigger-kind", "database-trigger-removed", "webhook-trigger-single", "webhook-trigger-table", "webhook-trigger-keys", "webhook-trigger-scheme-required", "webhook-trigger-scheme-none", "webhook-trigger-number", "webhook-trigger-dedup-boolean", "webhook-trigger-verification-table", "cron-trigger-cap", "cron-trigger-entry", "cron-trigger-keys", "cron-trigger-name-required", "cron-trigger-name-charset", "cron-trigger-duplicate", "cron-trigger-expression-required", "cron-trigger-overlap-policy"];
+export type TriggerRuleId = (typeof TRIGGER_RULE_IDS)[number];
+/**
+ * A broken trigger rule. `ruleId` names which one, for a reader that wants to
+ * branch without matching prose; every existing site reads `message` only.
+ * Optional so `new TriggerDeclarationError(message)` — the CLI's own parse
+ * refusal in `function-sync.ts` — keeps constructing.
+ */
+export declare class TriggerDeclarationError extends Error {
+    readonly ruleId?: TriggerRuleId;
+    constructor(message: string, ruleId?: TriggerRuleId);
+}
+/** Is anything at all declared? Used to skip work on the common case. */
+export declare function hasDeclaredTriggers(declaration: TriggerDeclaration): boolean;
+/**
+ * Normalize the `triggers` table of an already-parsed `[function]` table.
+ * Throws `TriggerDeclarationError` naming the rule that was broken.
+ *
+ * Split out from the parse (`deriveTriggerDeclaration`, which owns the bytes)
+ * so the CLI's preflight can check the document it has already read, and so the
+ * push boundary can normalize a declaration it read from a stored row without
+ * re-parsing bytes.
+ */
+export declare function normalizeTriggerDeclaration(functionTable: any): TriggerDeclaration;
+/** The stored JSON for `ServerFunctionConfig.triggers`, or null when empty. */
+export declare function serializeTriggerDeclaration(declaration: TriggerDeclaration): string | null;
+/** Read a stored `ServerFunctionConfig.triggers` value back. */
+export declare function parseStoredTriggerDeclaration(stored: unknown): TriggerDeclaration;
+/**
+ * The database types a STORED declaration used to watch, for a reader that
+ * wants to name them — #3483.
+ *
+ * Pure, and separate from the parse on purpose: the parse answers what the
+ * version means NOW (nothing), and this answers what it said, which is only
+ * ever used to write one log line. Nothing branches on it.
+ */
+export declare function storedDatabaseTriggerTypes(stored: unknown): string[];
+/** The `CronTrigger.triggerKey` an entry owns. */
+export declare function cronTriggerKeyFor(functionKey: string, name: string): string;
+/** The entry name a `<functionKey>:<name>` trigger key carries. */
+export declare function cronTriggerNameFrom(functionKey: string, triggerKey: string): string;
+/**
+ * The `{{secrets.KEY}}` reference SHAPE, decided from the value alone.
+ *
+ * Split out of `src/services/secret-templates.ts` by #3320 so the one rule that
+ * says whether a stored value IS a whole secret reference has one
+ * implementation on both sides of a `config push`. The CLI preflight refuses a
+ * webhook trigger whose `signingSecret` is a literal before anything is applied,
+ * and the server refuses the same value at the write boundary, because both run
+ * this code — the CLI through the artifact `cli/scripts/gen-config-surfaces.mjs`
+ * renders, the server by importing this module. A shape-only restatement in the
+ * CLI would have been subtly different: a reference spoiled by an invisible
+ * character (#2297) survives `String.trim()` and would have passed a preflight
+ * the server then failed.
+ *
+ * Pure by construction, which is what lets it live here: no secret store is
+ * consulted, because whether a value is a REFERENCE never depends on which keys
+ * exist. Whether the referenced key exists is the server's question, and stays
+ * in `secret-templates.ts` beside the rest of resolution.
+ *
+ * `secret-templates.ts` re-exports everything here, so every existing caller
+ * keeps its import and the two can never be different functions.
+ */
+export declare const SECRETS_TEMPLATE_RE: RegExp;
+/** True when the value carries at least one `{{secrets.KEY}}` reference. */
+export declare function isSecretTemplate(value: string | null | undefined): boolean;
+/**
+ * The value with every well-formed `{{secrets.KEY}}` reference removed — the
+ * text that was NOT part of a reference the grammar accepts.
+ *
+ * This is the string the leftover-syntax rule below has to judge, and it is
+ * always derived from the ORIGINAL stored value, never from a substituted
+ * result. Resolution is a single `String.replace` pass that never re-scans
+ * replacement text (`resolveMultiNamespaceTemplate`), so a brace or a
+ * `secrets.` token coming out of a SECRET'S VALUE is inert — it is credential
+ * material the operator stored, not config text, and testing the substituted
+ * output would reject it (a Stripe key suffix stored as `}v2{` in an otherwise
+ * valid `sk_live_{{secrets.SUFFIX}}` value).
+ */
+export declare function withoutSecretReferences(value: string): string;
+/**
+ * True when the value holds a well-formed `{{secrets.KEY}}` reference and the
+ * text beside it is not credential material — a reference SPOILED by an
+ * invisible character, rather than a legacy literal that happens to contain one
+ * (#2297, consolidating #2386).
+ *
+ * Such a value is a reference spoiled by an authoring mistake — pasted out of
+ * an editor or a document that carried a zero-width character along with it —
+ * and it must fail closed rather than resolve. Before this rule a value spelled
+ * `<U+200B>{{secrets.KEY}}` was not a whole reference (neither `\s` nor
+ * `String.trim()` matches U+200B), carried no leftover reference SYNTAX once
+ * the template was removed, and so classified as a working legacy literal that
+ * resolved to U+200B followed by the secret: an HMAC key silently one byte
+ * wrong, and a read surface pointing the operator at the wrong remediation.
+ *
+ * The rule judges the REMAINDER — the value with its well-formed references
+ * taken out — against an allowlist, which is what makes the class closed:
+ *
+ * - Remainder empty, or ordinary whitespace only: the value is the reference it
+ *   plainly is, padding and all, and keeps resolving (#2191).
+ * - Remainder carries at least one credential character: a genuine mixed
+ *   literal-plus-reference value (`sk_live_{{secrets.SUFFIX}}`), which predates
+ *   reference-only and keeps resolving as shipped (#2332) — including when the
+ *   operator's own bytes contain an invisible character, because that is
+ *   credential material rather than a spoiled pointer.
+ * - Anything else: text that is present but that we cannot recognize as
+ *   credential material. Fail closed.
+ *
+ * Failing closed rather than stripping the character is the deliberate choice
+ * (sponsor decision on #2297): stripping hides the mistake, where a
+ * `malformed-reference` names it at the moment the value is written.
+ *
+ * A value with NO well-formed reference is not this rule's business, and needs
+ * no separate handling: a pure literal is credential material the platform has
+ * no standing to judge (`whsec_<U+200B>raw`), and a MISTYPED reference —
+ * including one spoiled inside the braces, `{{secrets.<U+200B>KEY}}` — leaves
+ * its syntax in the remainder and is already caught by
+ * `carriesMalformedReferenceSyntax` in `secret-templates.ts`.
+ *
+ * Scoped to the reference-only credential boundary, not to
+ * `resolveSecretTemplate`: an integration proxy header is a template by design
+ * (`Authorization: Bearer {{secrets.TOKEN}}`), so it keeps resolving exactly
+ * what the operator wrote.
+ */
+export declare function isSpoiledSecretReference(value: string | null | undefined): boolean;
+/**
+ * Matches a value that is EXACTLY one `{{secrets.KEY}}` reference and nothing
+ * else. Anchored, and deliberately not global — `SECRETS_TEMPLATE_RE` carries
+ * `lastIndex` state between calls.
+ */
+export declare const WHOLE_SECRET_REFERENCE_RE: RegExp;
+/**
+ * True when the whole (trimmed) value is a single `{{secrets.KEY}}` reference.
+ *
+ * The stricter sibling of `isSecretTemplate`, for the callers that use "is a
+ * reference" to mean "carries no secret material of its own". `isSecretTemplate`
+ * is a *contains* test, so `"sk_live_abcd{{secrets.SUFFIX}}"` satisfies it —
+ * which is fine where a value is a template to be resolved (an
+ * `Authorization: Bearer {{secrets.TOKEN}}` header is exactly that), and wrong
+ * where the value is a credential that must live entirely in the encrypted
+ * secret store. Used by the webhook `config` credential rule and by the
+ * redaction that backs it: a mixed value would otherwise pass the write rule
+ * AND skip redaction, storing and echoing most of a working credential in
+ * cleartext.
+ *
+ * Trimmed, so `" {{secrets.KEY}} "` is accepted as the reference it plainly is;
+ * two references, or a reference with any literal text beside it, are not.
+ *
+ * Invisible text beside the reference disqualifies the value before the trim
+ * (#2297): U+FEFF is stripped by `String.trim()` and matched by `\s`, so
+ * without the check a byte-order mark beside the braces would be silently
+ * accepted while its zero-width siblings were not. Rejecting here is what makes
+ * the write gates built on this predicate (`validateWholeSecretReference`, the
+ * webhook `config` credential rule) refuse such a value at configuration time
+ * rather than storing a row that can only fail at use time.
+ */
+export declare function isWholeSecretReference(value: string | null | undefined): boolean;
+/**
+ * The `signingSecret` rule a webhook's verification scheme carries, decided
+ * from the declaration alone (#3320).
+ *
+ * `signingSecret` is reference-only (#2254): a whole `{{secrets.KEY}}`
+ * reference naming an app secret, and nothing else. Which schemes need one,
+ * whether one was supplied, and whether the supplied value is a reference are
+ * all answerable from the file — so they belong in the `config push` preflight,
+ * which aborts before anything is applied, rather than in the apply loop where
+ * a refusal lands after sibling entities are already written.
+ *
+ * That is the whole reason this module exists here rather than beside the rest
+ * of the webhook write pipeline: `src/config-surface/` is vendored verbatim
+ * into `cli/src/lib/generated-config-surfaces.ts`, so the CLI runs the server's
+ * rule instead of a restatement of it, and a change that is not regenerated
+ * fails `gen-config-surfaces.mjs --check`.
+ *
+ * ── What is deliberately NOT here ─────────────────────────────────────────
+ *
+ * Everything that needs the app's state: whether the referenced secret exists,
+ * whether the scheme's `config` is valid under this environment's JWKS policy,
+ * the per-app row cap, a key a standalone webhook already holds. Those stay in
+ * `src/app-api/services/webhook-settings-validation.ts`, which has `Env`. A
+ * local copy of them would be a preflight that gives a false all-clear — and
+ * the residue is then app-state-dependent by construction rather than by
+ * accident of where a rule happened to live.
+ */
+/**
+ * Schemes that don't carry an HMAC `signingSecret`. These either store no key
+ * material at all (`none`) or store it under `AppWebhook.config` instead:
+ * `discord` puts the application public key in `config.publicKey`, `jwt` puts
+ * a JWKS in `config.jwt.jwks`, and `plaid` fetches keys from Plaid using the
+ * API credentials referenced in `config.plaid`.
+ */
+export declare const SCHEMES_WITHOUT_SIGNING_SECRET: readonly string[];
+export declare function requiresSigningSecret(scheme: unknown): boolean;
+/** The coded refusals, so a client can branch without matching prose. */
+export declare const SIGNING_SECRET_MUST_BE_SECRET_REF = "SIGNING_SECRET_MUST_BE_SECRET_REF";
+export declare const SIGNING_SECRET_NOT_SUPPORTED_FOR_SCHEME = "SIGNING_SECRET_NOT_SUPPORTED_FOR_SCHEME";
+/**
+ * The rule ids this module owns, declared on the `function` surface as
+ * `preflight` and on the `webhook` surface as `apply` (#3374) — one rule, two
+ * surfaces, one handler. `whole-secret-reference` is generic on purpose:
+ * `validateWholeSecretReference` is reused by the Google client secret and by
+ * both webhook controllers under their own labels and codes.
+ */
+export declare const SIGNING_SECRET_RULE_IDS: readonly ["signing-secret-required", "whole-secret-reference", "signing-secret-not-supported"];
+type SigningSecretRuleId = (typeof SIGNING_SECRET_RULE_IDS)[number];
+/**
+ * A refusal from this rule. `plain` marks the ones the admin webhook create
+ * answered as a bare text body rather than coded JSON — an observable
+ * distinction, so it travels with the error rather than being flattened.
+ * `ruleId` names the rule and never reaches the wire: every reader picks
+ * `message`, `code` and `plain`.
+ */
+export interface SigningSecretRuleError {
+    ruleId: SigningSecretRuleId;
+    message: string;
+    code?: string;
+    plain?: boolean;
+}
+/** The reference-only message, shared by every field that carries one. */
+export declare function wholeSecretReferenceMessage(label: string): string;
+/**
+ * Is this value a whole `{{secrets.KEY}}` reference? Returns the refusal a
+ * caller renders, or null.
+ *
+ * `isWholeSecretReference`, never `isSecretTemplate`: a *contains* test admits
+ * `sk_live_abcd{{secrets.SUFFIX}}`, which stores most of a working credential
+ * in cleartext.
+ */
+export declare function validateWholeSecretReference(label: string, value: unknown, code: string): SigningSecretRuleError | null;
+/**
+ * The whole file-decidable `signingSecret` rule, in the order the standalone
+ * webhook create ran it: a required secret must be present, a present one must
+ * be a whole reference, and a scheme that carries no secret must not be given
+ * one.
+ *
+ * Returns null when the declaration is acceptable — which does NOT mean the
+ * write will succeed: the referenced key still has to exist, and that is the
+ * server's question.
+ */
+export declare function validateSigningSecretDeclaration(input: {
+    verificationScheme: string;
+    signingSecret?: unknown;
+}): SigningSecretRuleError | null;
+/**
+ * The workflow rules two runners share (#3374, project `cli-server-rule-parity`
+ * phase 2; intent §Success criteria 3).
+ *
+ * ── One predicate, two messages ──────────────────────────────────────────
+ *
+ * `runAs = "system"` beside a non-empty `accessRule` is dead config: a system
+ * run can only be started by the system and never evaluates its access rule
+ * (#1258, broadening #1172). The server refused it at save time
+ * (`validateWorkflowIdentityConfig`) and the CLI refused it in the push
+ * preflight (`validateWorkflowIdentity`), and the two carried the conjunction
+ * byte-for-byte as separate copies kept in step by a comment. This module is
+ * the one copy: it decides, and returns a STRUCTURED violation — the rule id
+ * and the server's sentence — that each site renders in its own words. The
+ * server pushes the sentence into its `string[]`; the CLI keeps its own hint,
+ * which names the preflight remedy. Neither message changed.
+ *
+ * ── Why a `*-rules.ts` module ────────────────────────────────────────────
+ *
+ * The registry's unclaimed-export check (`findUnclaimedRuleModuleExports`)
+ * keys on this name under `src/config-surface/`: every exported function here
+ * is a rule, so one no surface declares fails `cli-unit-tests`. Shared
+ * predicates that are not rules live elsewhere (`webhook-signing-secret.ts`).
+ * The module is vendored into the CLI artifact like the rest of the
+ * directory, which is what lets `workflow`'s declaration call the rule
+ * `preflight`.
+ */
+/** The rule ids this module owns — the union type below anchors them (#3373). */
+export declare const WORKFLOW_RULE_IDS: readonly ["system-access-rule"];
+type WorkflowRuleId = (typeof WORKFLOW_RULE_IDS)[number];
+/** A violation of one of this module's rules, for a site to render. */
+export interface WorkflowRuleViolation extends RuleRefusal<WorkflowRuleId> {
+}
+/**
+ * `runAs = "system"` with a non-empty string `accessRule`, or null.
+ *
+ * Exactly the conjunction both sites carried: a default, unset, empty or
+ * whitespace-only rule is no rule, and a non-string one (`accessRule = false`)
+ * is malformed input for another check to name, not dead config. The message
+ * is the server's save-time sentence; the CLI renders its own hint from the
+ * same answer.
+ */
+export declare function checkWorkflowSystemAccessRule(input: {
+    runAs?: unknown;
+    accessRule?: unknown;
+}): WorkflowRuleViolation | null;
+export declare const WORKFLOW_SURFACE: ConfigObjectSurface;
+/**
+ * Cron-expression and timezone VALIDITY — the half of `src/cron-parser.ts`
+ * both runners need (#3376, project `cli-server-rule-parity` phase 4).
+ *
+ * ── Why this module exists ───────────────────────────────────────────────
+ *
+ * A malformed cron expression and an unknown timezone are both decidable from
+ * the authored file, so the intent lands both rules `preflight` — which under
+ * this project's vocabulary means the implementation lives here, under
+ * `src/config-surface/`, and is vendored into the CLI artifact.
+ *
+ * It got here by a SPLIT, not a move. `src/cron-parser.ts` is 415 lines, and
+ * roughly 290 of them are timezone-aware scheduling arithmetic — "when does
+ * this expression next fire?" — that only the cron Durable Object runs.
+ * Vendoring is wholesale: the generator concatenates this whole directory, so
+ * moving the file would have shipped that scheduler into the published CLI
+ * package. The validator moved; the scheduler stayed; `src/cron-parser.ts`
+ * re-exports what moved, so no server import changed.
+ *
+ * The scheduler's two entry points are deliberately not NAMED here: a CLI
+ * unit test asserts the artifact does not contain either identifier, which is
+ * how "the artifact carries the validator only" is kept true mechanically
+ * rather than by review.
+ *
+ * ── Not a rules module ───────────────────────────────────────────────────
+ *
+ * `parseCron` THROWS, eight different sentences, and `tests/unit/
+ * cron-parser.test.ts` pins that it throws. A module exporting a `*_RULE_IDS`
+ * list may not contain a `throw` outside its one refusal constructor
+ * (`findUnanchoredRefusals`, #3373), so the rule that renders these answers as
+ * refusals is a separate module, `cron-rules.ts`, and this one is a plain
+ * shared-predicate module — the `webhook-signing-secret.ts` / `function-mode.ts`
+ * precedent.
+ *
+ * Pure: no models, no tenant context, no `env` (see `types.ts` §Purity).
+ * `Intl.DateTimeFormat` is the one platform call, and it is the timezone
+ * question itself.
+ *
+ * Supported fields (standard POSIX order):
+ *   minute (0-59)
+ *   hour (0-23)
+ *   day-of-month (1-31)
+ *   month (1-12)
+ *   day-of-week (0-6, where 0 = Sunday; 7 also accepted as Sunday)
+ *
+ * Supported syntax per field:
+ *   - "*"          any value
+ *   - "5"          exact value
+ *   - "5-10"       range (inclusive)
+ *   - "star/step"  every N values within the full range (e.g. "* /5" => 0,5,10,...)
+ *   - "a-b/step"   every N values within a range
+ *   - "1,2,3"      comma-separated list of values or ranges
+ *
+ * Not supported: month/day names, "?", "L", "W", "#", last-day modifiers.
+ */
+export interface ParsedCron {
+    minutes: Set<number>;
+    hours: Set<number>;
+    daysOfMonth: Set<number>;
+    months: Set<number>;
+    daysOfWeek: Set<number>;
+    dayOfMonthWild: boolean;
+    dayOfWeekWild: boolean;
+}
+export declare function parseCron(expr: string): ParsedCron;
+/**
+ * The message `parseCron` would throw for `expr`, or null when it parses.
+ *
+ * The same grammar, asked as a question instead of as an exception, because
+ * both callers want the sentence rather than the control flow: the CLI's push
+ * preflight collects one message per broken entry, and the standalone cron
+ * routes render theirs into a 400 body. `expr` is typed `unknown` because it
+ * arrives as an authored TOML value, where it can be anything at all.
+ */
+export declare function cronExpressionError(expr: unknown): string | null;
+/**
+ * Whether `Intl.DateTimeFormat` accepts `name` as a timezone.
+ *
+ * This is THE timezone check — before #3376 the identical probe was written
+ * out three times (the function push boundary and the standalone create and
+ * update). Each of those sites keeps its own sentence and its own defaulting;
+ * what they now share is this answer. A non-string is false rather than a
+ * throw, for the same reason as above.
+ */
+export declare function isValidTimezone(name: unknown): boolean;
+/**
+ * The cron schedule rules two runners share (#3376, project
+ * `cli-server-rule-parity` phase 4; intent §Success criteria 6).
+ *
+ * ── One implementation, two runners ──────────────────────────────────────
+ *
+ * A cron expression the grammar refuses, and a timezone `Intl` does not know,
+ * are both decidable from the authored file. Before this issue only the SERVER
+ * decided them, inside the apply loop: a `functions/<key>.toml` carrying
+ * either passed `config push`'s preflight, sibling entities were written, and
+ * the function alone was refused — while the command promises that a refusal
+ * means nothing was applied. Now `cli/src/lib/function-sync.ts` and
+ * `src/services/function-trigger-validation.ts` both call the rule below, and
+ * the sentence an author reads is the same on either side of the wire because
+ * it is built in one place.
+ *
+ * ── Why this is a `*-rules.ts` module and the parser is not ──────────────
+ *
+ * The registry's unclaimed-export check (`findUnclaimedRuleModuleExports`)
+ * keys on this name under `src/config-surface/`: every exported function here
+ * is a rule, so one no surface declares fails `cli-unit-tests`. The anchor
+ * also forbids a `throw` outside the one refusal constructor — and `parseCron`
+ * throws eight different sentences, which `tests/unit/cron-parser.test.ts`
+ * pins. So the grammar and the `Intl` probe live next door in
+ * `cron-expression.ts`, which is a shared-predicate module rather than a rules
+ * module, and this one only decides and renders.
+ *
+ * ── What is NOT shared ───────────────────────────────────────────────────
+ *
+ * The standalone cron routes ask the same two predicates and render their own
+ * `Invalid cron expression: …` / `Invalid timezone: …`, with their own
+ * defaulting (create reads an absent timezone as UTC, update does not). That
+ * is intent assumption 2 in the form its own fallback describes, and the shape
+ * `workflow-rules.ts` set in phase 2: one predicate, each site's message and
+ * defaulting preserved. No refusal message changed anywhere.
+ */
+/** The rule ids this module owns — the union type below anchors them (#3373). */
+export declare const CRON_TRIGGER_RULE_IDS: readonly ["cron-trigger-expression", "cron-trigger-timezone"];
+type CronTriggerRuleId = (typeof CRON_TRIGGER_RULE_IDS)[number];
+/** A refused cron entry: the rule and the sentence the site renders. */
+export type CronTriggerRuleRefusal = RuleRefusal<CronTriggerRuleId>;
+/**
+ * One `[[function.triggers.cron]]` entry's schedule, or null.
+ *
+ * Expression first, then timezone, which is the order the push boundary ran
+ * them in — so an entry broken both ways still answers with the expression's
+ * refusal, exactly as before. An unset or empty `timezone` reads as UTC, again
+ * exactly as before: the boundary's `entry.timezone || "UTC"`.
+ */
+export declare function checkCronTriggerEntry(entry: {
+    name: string;
+    cron: string;
+    timezone?: string;
+}): CronTriggerRuleRefusal | null;
+/**
+ * The prompt config's reasoning controls, resolved onto each provider's own
+ * spelling — issue #3358.
+ *
+ * A `[[configs]]` entry states EITHER `reasoningEffort` (a provider-neutral
+ * level, `none` through `high`) or `reasoningBudget` (a token count), never
+ * both. This module is the whole translation: every authored pair either maps
+ * onto the provider's native key or is REFUSED with a message naming the
+ * remedy. Nothing is dropped — that was the trap `providerConfig` already laid
+ * in the tree (stored, serialized, round-tripped, and never read at execution),
+ * and the issue's third success criterion is precisely that a config asking for
+ * something a provider cannot express fails rather than silently doing nothing.
+ *
+ * Pure and dependency-free, like every module under `src/config-surface/`: the
+ * server's create/update handlers, the executor, and the vendored CLI artifact
+ * all read this one copy, so a refusal at push and a refusal at execution
+ * cannot disagree.
+ *
+ * Provider facts this encodes:
+ *
+ *  - OpenRouter takes a unified `reasoning` block: `{ effort }`,
+ *    `{ max_tokens }`, or `{ enabled: false }` to decline it. `max_tokens` is an
+ *    exact bound on budget-native models and is translated to the nearest
+ *    effort level on effort-only ones, so it is documented as a bound, not a
+ *    guarantee — `metrics.reasoningTokens` is the measure of what was spent.
+ *    Default routing lets an endpoint IGNORE a parameter it does not support,
+ *    so a request carrying `reasoning` also carries
+ *    `provider: { require_parameters: true }`: an endpoint that cannot honor it
+ *    is refused by OpenRouter and surfaces as a failed execution rather than a
+ *    silent drop.
+ *  - Gemini 3.x expresses thinking as a LEVEL
+ *    (`thinkingConfig.thinkingLevel`) and cannot turn it off; `thinkingBudget`
+ *    is accepted there only for backward compatibility and is translated to a
+ *    level rather than honored as a bound, so a numeric budget is refused with
+ *    a pointer at `reasoningEffort`.
+ *  - Gemini 2.5 expresses it as a numeric BUDGET
+ *    (`thinkingConfig.thinkingBudget`); `0` turns thinking off on Flash and
+ *    Flash-Lite, while Pro has a floor of 128 and answers 400 for less.
+ *  - Gemini 2.0 and earlier have no thinking control at all.
+ */
+/** The provider-neutral effort levels a config may state. */
+export declare const REASONING_EFFORTS: readonly ["none", "minimal", "low", "medium", "high"];
+export type ReasoningEffort = (typeof REASONING_EFFORTS)[number];
+/** The smallest budget Gemini 2.5 Pro accepts; it cannot stop thinking. */
+export declare const GEMINI_PRO_MIN_THINKING_BUDGET = 128;
+export interface PromptReasoningInput {
+    provider?: string | null;
+    model?: string | null;
+    reasoningEffort?: string | null;
+    reasoningBudget?: number | string | null;
+}
+/** What the executor adds to the upstream request, or `null` for "unset". */
+export type PromptReasoningDirective = {
+    provider: "openrouter";
+    /** The OpenRouter `reasoning` block. */
+    reasoning: Record<string, unknown>;
+    /**
+     * `provider: { require_parameters: true }` — routing restricted to
+     * endpoints that support every parameter in the request.
+     */
+    requireParameters: true;
+} | {
+    provider: "gemini";
+    /** The `generationConfig.thinkingConfig` block. */
+    thinkingConfig: Record<string, unknown>;
+};
+export type PromptReasoningResolution = {
+    ok: true;
+    directive: PromptReasoningDirective | null;
+} | {
+    ok: false;
+    error: string;
+};
+/**
+ * How a Gemini model spells its thinking control.
+ *
+ * `level` — Gemini 3.x, `thinkingLevel`, cannot be turned off.
+ * `budget` — Gemini 2.5, `thinkingBudget` in tokens.
+ * `none` — Gemini 2.0 and earlier, no control at all.
+ */
+export type GeminiReasoningFamily = "level" | "budget" | "none";
+export declare function geminiReasoningFamily(model: string): GeminiReasoningFamily;
+/** Gemini Pro: the tier that cannot stop thinking in either family. */
+export declare function isGeminiProModel(model: string): boolean;
+/** Is EITHER reasoning key stated on this config? */
+export declare function hasPromptReasoning(input: PromptReasoningInput): boolean;
+/**
+ * Resolve an authored pair onto the provider's spelling.
+ *
+ * Returns `{ ok: true, directive: null }` when neither key is set — the case
+ * that must leave the upstream payload byte-identical to what it was before
+ * this issue — a directive when the pair maps, and `{ ok: false, error }` when
+ * it does not. The error text is what `config push` reports as the file's
+ * error and what the admin routes answer 400 with.
+ */
+export declare function resolvePromptReasoning(input: PromptReasoningInput): PromptReasoningResolution;
+/**
+ * What a prompt's KIND admits — issue #3626.
+ *
+ * A prompt declares `[prompt] kind = "chat" | "decisions" | "agent"`. The kind decides
+ * the input envelope (`variables` rendered into templates for chat, a `state`
+ * value for decisions), the provider endpoint the executor posts to, and which
+ * `[configs.<kind>]` block a `[[configs]]` entry may carry. Adding a kind is a
+ * group declaration plus its fields, not another round of implicit
+ * discrimination: the earlier design inferred "this is a decisions config" from
+ * the presence of `questions` on a table otherwise shaped for chat, and refused
+ * the nine chat keys one by one.
+ *
+ * This module is the whole rule. `resolvePromptKind` is called by the CLI's
+ * push preflight through the vendored artifact, by `createAppPrompt`,
+ * `createPromptConfig` and `updatePromptConfig`, so a refusal at push and a
+ * refusal at the admin route cannot disagree — the `resolvePromptReasoning`
+ * posture of #3358, for the same reason.
+ *
+ * Pure and dependency-free, like every module under `src/config-surface/`.
+ */
+/**
+ * The kinds a prompt may declare. An omitted `kind` is `chat`.
+ *
+ * #3798 — `agent` is a prompt run turn by turn in a session: no template, no
+ * output schema, never run single-shot. Its tools and events are declared in
+ * `[prompt.agent]` (`agent-declaration.ts`); its configs carry
+ * `[configs.agent]`.
+ */
+export declare const PROMPT_KINDS: readonly ["chat", "decisions", "agent"];
+export type PromptKind = (typeof PROMPT_KINDS)[number];
+/**
+ * The nine chat settings that existed before `[configs.chat]` did. Only these
+ * keep the deprecated FLAT spelling (#3642): a key added to the block later was
+ * never written flat by any file, so it has none (the `questions` posture,
+ * SO3626-013).
+ */
+export declare const LEGACY_FLAT_CHAT_KEYS: readonly ["systemPrompt", "userPromptTemplate", "temperature", "topP", "maxTokens", "outputFormat", "outputSchema", "reasoningEffort", "reasoningBudget"];
+/**
+ * The settings that describe a CHAT COMPLETION and nothing else. They are
+ * authored under `[configs.chat]`; the flat spelling of the nine legacy keys
+ * is deprecated (#3642).
+ *
+ * #3801 — `strictOutput`, the opt-in that sends `[prompt].outputSchema` as a
+ * strict `json_schema` on OpenRouter (`prompt-strict-output.ts`). Not an agent
+ * key (§D1: an agent has no output schema), so the agent arm refuses it.
+ */
+export declare const CHAT_CONFIG_KEYS: readonly ["systemPrompt", "userPromptTemplate", "temperature", "topP", "maxTokens", "outputFormat", "outputSchema", "reasoningEffort", "reasoningBudget", "strictOutput"];
+export type ChatConfigKey = (typeof CHAT_CONFIG_KEYS)[number];
+/** The settings that describe a DECISIONS request. */
+export declare const DECISIONS_CONFIG_KEYS: readonly ["questions"];
+/**
+ * #3798 — the settings of an AGENT's model round: the chat block less
+ * `userPromptTemplate` (the model sees each message as sent), `outputFormat`
+ * and `outputSchema` (an agent's final answer is text; anything structured is
+ * a tool call). The same wire keys as chat, authored under `[configs.agent]`.
+ */
+export declare const AGENT_CONFIG_KEYS: readonly ["systemPrompt", "temperature", "topP", "maxTokens", "reasoningEffort", "reasoningBudget"];
+/**
+ * The WIRE field names each kind's block holds. The config surface declares the
+ * same grouping through `ConfigField.tomlGroup`, and the drift guard asserts
+ * the two agree — so a chat key added to the surface without a home here (or
+ * the reverse) fails `cli-unit-tests` rather than being accepted under a
+ * decisions prompt.
+ */
+export declare const PROMPT_KIND_BLOCKS: Readonly<Record<PromptKind, readonly string[]>>;
+/** The question types TypeSafe's System One models answer. */
+export declare const DECISIONS_QUESTION_TYPES: readonly ["choice", "score", "noul"];
+export type DecisionsQuestionType = (typeof DECISIONS_QUESTION_TYPES)[number];
+/**
+ * #3813 — where a `choice` question's options come from. `"static"`: the
+ * config's `criteria` table. `"dynamic"`: each run supplies the table as
+ * `variables.criteria.<question>`. Required on every `choice` question, with
+ * no default, and a platform key: it is removed before the provider request.
+ */
+export declare const DECISIONS_CRITERIA_SOURCES: readonly ["static", "dynamic"];
+export type DecisionsCriteriaSource = (typeof DECISIONS_CRITERIA_SOURCES)[number];
+/**
+ * #3813 — the code a decisions run carries when the options it was asked to
+ * choose between are refused before the provider call: malformed per-run
+ * criteria, criteria for a question that does not take them, or a stored
+ * `choice` question that does not say where its options come from.
+ */
+export declare const PROMPT_CRITERIA_INVALID = "PROMPT_CRITERIA_INVALID";
+/**
+ * The prompt's kind, normalized.
+ *
+ * Every reader goes through this: rows created before #3626 carry no `kind`
+ * attribute at all, and an absent one is `chat` everywhere — the detail route,
+ * pull, diff, execution and codegen.
+ */
+export declare function promptKindOf(prompt: unknown): PromptKind;
+/** The config values the rule reads — the wire spelling, not the TOML one. */
+export interface PromptKindConfigInput {
+    systemPrompt?: unknown;
+    userPromptTemplate?: unknown;
+    temperature?: unknown;
+    topP?: unknown;
+    maxTokens?: unknown;
+    outputFormat?: unknown;
+    outputSchema?: unknown;
+    reasoningEffort?: unknown;
+    reasoningBudget?: unknown;
+    /** #3801 — a chat key; the agent and decisions arms refuse it. */
+    strictOutput?: unknown;
+    questions?: unknown;
+}
+export interface PromptKindInput {
+    /** `[prompt].kind`. `null`, `undefined` and `""` are unset, meaning `chat`. */
+    kind?: unknown;
+    provider?: unknown;
+    model?: unknown;
+    /**
+     * The EFFECTIVE config: the payload value where the request carries one, the
+     * stored value otherwise. `outputSchema` here is the CONFIG's own field —
+     * never the prompt-level schema, which is legal on either kind (§3, SO3626-003).
+     */
+    config: PromptKindConfigInput;
+}
+export type PromptKindResolution = {
+    ok: true;
+    kind: "chat";
+} | {
+    ok: true;
+    kind: "decisions";
+    questions: Record<string, unknown>;
+} | {
+    ok: true;
+    kind: "agent";
+} | {
+    ok: false;
+    error: string;
+    code?: string;
+};
+/**
+ * The one rule: does this (kind, provider, config) triple describe something
+ * the platform can run?
+ *
+ * `{ ok: true, kind: "chat" }` is today's behavior byte for byte. The decisions
+ * arm returns the NORMALIZED questions so the caller stores one spelling
+ * whichever transport the author used.
+ */
+export declare function resolvePromptKind(input: PromptKindInput): PromptKindResolution;
+export type DecisionsRunQuestionsResolution = {
+    ok: true;
+    questions: Record<string, unknown>;
+} | {
+    ok: false;
+    error: string;
+};
+/**
+ * #3813 — the questions one run sends to the provider.
+ *
+ * `questions` is the RAN config's declaration, as stored; `runCriteria` is
+ * the run's `variables.criteria` (`undefined` when the run sent none). A
+ * `"dynamic"` question is given the run's table as its `criteria`; every
+ * question loses `criteriaSource`, which is the platform's key and not the
+ * endpoint's. The config still owns each question's name, type and
+ * instructions: a run can supply options only for a question declared
+ * `"dynamic"`, so nothing a run sends can change what is being asked.
+ *
+ * Refuses, before any provider call: a `variables.criteria` that is not an
+ * object; criteria for a name the config does not declare, for a `"static"`
+ * question, or for a `score` or `noul` one; a `"dynamic"` question with no
+ * table or a table the criteria rule refuses; and a stored `choice` question
+ * with no usable `criteriaSource` — a config written before the key existed,
+ * which is refused rather than given a silent default.
+ *
+ * Pure: the stored questions object is never mutated.
+ */
+export declare function resolveDecisionsRunQuestions(questions: Record<string, unknown>, runCriteria: unknown): DecisionsRunQuestionsResolution;
+/** What the hoist did to one `[[configs]]` entry. */
+export interface DeprecatedChatKeyHoist {
+    /** A COPY of the entry with the flat chat keys moved under `chat`. */
+    entry: Record<string, unknown>;
+    /** The flat keys that were moved, sorted — what the warning names. */
+    moved: string[];
+    /** Keys set BOTH flat and under `[configs.chat]`; the caller refuses these. */
+    conflicts: string[];
+}
+/**
+ * Move the deprecated flat chat keys of one `[[configs]]` entry under `chat`
+ * — #3626 §4, the blob-bucket `accessPolicy` precedent made reusable.
+ *
+ * Push keeps accepting the nine keys flat so no existing file breaks, and pull
+ * rewrites them, so one pull-then-push migrates a file. A key present in BOTH
+ * spellings is not merged: the grouped value is left standing and the key is
+ * reported in `conflicts`, which the caller turns into a refusal naming the
+ * entry. Nothing else in the entry is touched — `providerConfig` is
+ * provider-keyed rather than chat-keyed (D3626-002) and `questions` has no flat
+ * spelling at all (SO3626-013).
+ */
+export declare function hoistDeprecatedChatKeys(entry: unknown): DeprecatedChatKeyHoist;
+/**
+ * Strict output for a chat config — issue #3801 (project `agents`, §D6).
+ *
+ * A chat prompt's OpenRouter request asks for JSON mode (`outputFormat =
+ * "json"`) and the answer is checked AFTERWARDS against `[prompt].outputSchema`
+ * (`derivePromptRunEnvelope`). A config that sets `[configs.chat].strictOutput
+ * = true` asks the provider to constrain the answer instead: the prompt-level
+ * schema is sent as `response_format: { type: "json_schema", json_schema: {
+ * name: "output", strict: true, schema } }`, with `provider: {
+ * require_parameters: true }` so OpenRouter refuses an endpoint that would
+ * ignore it rather than dropping it in silence (the #3358 posture).
+ *
+ * This module is the whole rule, and it is read in both places a config is
+ * written: the admin routes, and (vendored) the CLI's push preflight, so a
+ * refusal at push and at the route cannot disagree — `resolvePromptReasoning`
+ * and `resolvePromptKind`'s posture.
+ *
+ * Which schema is sent is never ambiguous: always the PROMPT's (§D6), so a
+ * config that also declares its own `outputSchema` is refused. Five refusals,
+ * in this order, each with its own code:
+ *
+ *  - `PROMPT_STRICT_OUTPUT_INVALID` — the value is not a boolean.
+ *  - `PROMPT_STRICT_OUTPUT_SCHEMA_CONFLICT` — the config declares its own
+ *    `outputSchema` too.
+ *  - `PROMPT_STRICT_OUTPUT_PROVIDER_UNSUPPORTED` — not OpenRouter. A Gemini
+ *    config already constrains its request through `responseSchema`.
+ *  - `PROMPT_STRICT_OUTPUT_FORMAT_CONFLICT` — `outputFormat = "text"`.
+ *  - `PROMPT_STRICT_OUTPUT_SCHEMA_MISSING` — the prompt declares no usable
+ *    `[prompt].outputSchema`.
+ *
+ * The first four are about the config itself and apply whatever its status.
+ * The last depends on PROMPT-level state that can change under a config, so it
+ * is skipped for an ARCHIVED config (DSO-3801-002): a retired strict config may
+ * be pulled, pushed and renamed after its prompt dropped the schema, and the
+ * requirement is enforced when a config is or becomes active — the #3799
+ * posture, "an archive is never checked".
+ *
+ * Pure and dependency-free, like every module under `src/config-surface/`.
+ */
+/** Every code the rule answers, in the order it checks. */
+export declare const PROMPT_STRICT_OUTPUT_CODES: readonly ["PROMPT_STRICT_OUTPUT_INVALID", "PROMPT_STRICT_OUTPUT_SCHEMA_CONFLICT", "PROMPT_STRICT_OUTPUT_PROVIDER_UNSUPPORTED", "PROMPT_STRICT_OUTPUT_FORMAT_CONFLICT", "PROMPT_STRICT_OUTPUT_SCHEMA_MISSING"];
+export type PromptStrictOutputErrorCode = (typeof PROMPT_STRICT_OUTPUT_CODES)[number];
+/**
+ * The one code a RUN can also carry: the executor refuses a strict config whose
+ * stored prompt schema is absent or unusable before any provider call, rather
+ * than downgrading the request to JSON mode.
+ */
+export declare const PROMPT_STRICT_OUTPUT_SCHEMA_MISSING = "PROMPT_STRICT_OUTPUT_SCHEMA_MISSING";
+/**
+ * `json_schema.name`. The OpenAI-shaped API requires one and the executor has
+ * no prompt key to hand, so it is fixed — the same request for the same schema.
+ */
+export declare const STRICT_OUTPUT_SCHEMA_NAME = "output";
+export interface PromptStrictOutputInput {
+    provider?: unknown;
+    /** `[configs.chat].strictOutput` as authored or stored. */
+    strictOutput?: unknown;
+    outputFormat?: unknown;
+    /** The CONFIG's own `outputSchema` — the one strict output never sends. */
+    configOutputSchema?: unknown;
+    /** `[prompt].outputSchema` — the one it does. */
+    promptOutputSchema?: unknown;
+    /** The config's effective status; absent is `active`. */
+    status?: unknown;
+}
+export type PromptStrictOutputResolution = {
+    ok: true;
+    strict: boolean;
+} | {
+    ok: false;
+    code: PromptStrictOutputErrorCode;
+    error: string;
+};
+/** Does this config opt in? Only a literal `true` does. */
+export declare function isStrictOutput(value: unknown): boolean;
+/**
+ * The schema strict output sends, from a stored or authored
+ * `[prompt].outputSchema`: a JSON object (or its text), else `null`.
+ */
+export declare function strictOutputSchemaOf(value: unknown): Record<string, unknown> | null;
+/**
+ * Is this (provider, strictOutput, outputFormat, schemas, status) a config the
+ * platform can run as strict — or not strict at all?
+ */
+export declare function resolvePromptStrictOutput(input: PromptStrictOutputInput): PromptStrictOutputResolution;
+/**
+ * What an agent prompt may declare — issue #3798 (project `agents`, §D1).
+ *
+ * An agent is a prompt of `kind = "agent"`. Its configs carry `[configs.agent]`
+ * (the rule for those is `resolvePromptKind`); its contract lives in ONE
+ * prompt-level block, `[prompt.agent]`: the tools the model may call, the event
+ * kinds members record, the turn context, how history is selected, who answers
+ * a paused call, and the limits an agent may lower but never raise.
+ *
+ * This module is the whole rule for that block. `resolveAgentDeclaration` is
+ * called by the CLI's push preflight through the vendored artifact and by the
+ * admin prompt routes, so a refusal at push and a refusal at the route cannot
+ * disagree — the `resolvePromptKind` posture of #3626.
+ *
+ * STORED AS WRITTEN (DSO-3798-001). The resolver returns the AUTHORED value —
+ * a block written as one JSON string is parsed to the object it encodes, and
+ * nothing is added. `config diff` compares a `json` field by value with no
+ * defaults applied, so a stored declaration with defaults filled in would read
+ * Modified after every push, and `config pull` would write keys the author
+ * never did. The defaults live in one reader instead, `normalizeAgentDeclaration`,
+ * which every consumer (the executor, codegen, the turn engine) calls.
+ *
+ * Every refusal carries a stable code (intent criterion 22) and a refusal lists
+ * EVERY offending item, so an author fixes a declaration in one pass.
+ *
+ * Pure and dependency-free, like every module under `src/config-surface/`.
+ */
+/** The stable codes every agent agentRefusal this project adds carries. */
+export declare const AGENT_ERROR_CODES: readonly ["AGENT_DECLARATION_INVALID", "AGENT_TOOL_FUNCTION_MISSING", "AGENT_TOOL_FUNCTION_SCHEMA_MISSING", "AGENT_OUTPUT_SCHEMA_NOT_ALLOWED", "AGENT_CONFIG_KEY_NOT_ALLOWED", "AGENT_NOT_RUNNABLE", "AGENT_TEST_CASE_NOT_SUPPORTED", "AGENT_SCHEMA_NOT_TRANSLATABLE", "AGENT_MODEL_UNKNOWN", "AGENT_MODEL_CAPABILITY_MISSING", "AGENT_MODEL_CAPABILITIES_UNAVAILABLE", "AGENT_ROUND_NOT_AGENT", "AGENT_ROUND_INPUT_INVALID", "AGENT_TOOL_UNKNOWN", "AGENT_TOOL_ARGUMENTS_INVALID", "AGENT_ROUND_TRUNCATED", "AGENT_ROUND_EMPTY"];
+export type AgentErrorCode = (typeof AGENT_ERROR_CODES)[number];
+/** One agentRefusal: the code a client branches on, and the sentence a person reads. */
+export interface AgentRefusal {
+    code: AgentErrorCode;
+    message: string;
+}
+/**
+ * The platform maximums. An agent may lower `maxSteps` and `waitLimitSeconds`,
+ * never raise them; the tool and event counts bound what one declaration can
+ * make every turn carry (principle 2).
+ */
+export declare const AGENT_LIMITS: {
+    readonly maxSteps: 25;
+    readonly waitLimitSeconds: 604800;
+    readonly tools: 64;
+    readonly events: 64;
+};
+/**
+ * A tool or event name: the intersection of OpenRouter's and Gemini's
+ * function-name rules, so one declaration maps onto either provider.
+ */
+export declare const AGENT_NAME: RegExp;
+export declare const AGENT_ANSWERED_BY: readonly ["initiator", "participants"];
+export declare const AGENT_TOOL_INVOKE: readonly ["request", "task"];
+export declare const AGENT_TOOL_HISTORY_SCOPES: readonly ["session", "turn"];
+export type AgentAnsweredBy = (typeof AGENT_ANSWERED_BY)[number];
+export type AgentToolInvoke = (typeof AGENT_TOOL_INVOKE)[number];
+export type AgentToolHistoryScope = (typeof AGENT_TOOL_HISTORY_SCOPES)[number];
+/** A JSON Schema object, as the declaration holds one. */
+export type AgentSchema = Record<string, unknown>;
+/** One `[[prompt.agent.tools]]` entry, as authored. */
+export interface AgentToolDeclaration {
+    name: string;
+    description: string;
+    /** A server tool: the function whose schemas are the tool's. */
+    function?: string;
+    invoke?: AgentToolInvoke;
+    /** A client tool: answered by a member's client, schemas in the TOML. */
+    runs?: "client";
+    inputSchema?: AgentSchema;
+    outputSchema?: AgentSchema;
+    approval?: boolean;
+    statusText?: string;
+    historyScope?: AgentToolHistoryScope;
+}
+/** One `[[prompt.agent.events]]` entry. */
+export interface AgentEventDeclaration {
+    name: string;
+    schema: AgentSchema;
+}
+/** `[prompt.agent]` as authored: every key optional. */
+export interface AgentDeclaration {
+    answeredBy?: AgentAnsweredBy;
+    maxSteps?: number;
+    waitLimitSeconds?: number;
+    turnContext?: {
+        schema: AgentSchema;
+        function?: string;
+    };
+    history?: {
+        function?: string;
+        maxHistoryChars?: number;
+    };
+    tools?: AgentToolDeclaration[];
+    events?: AgentEventDeclaration[];
+}
+/** A tool with its defaults applied. */
+export type NormalizedAgentTool = AgentToolDeclaration & {
+    approval: boolean;
+    historyScope: AgentToolHistoryScope;
+};
+/** The declaration with every default applied — what readers consume. */
+export interface NormalizedAgentDeclaration {
+    answeredBy: AgentAnsweredBy;
+    maxSteps: number;
+    waitLimitSeconds: number;
+    turnContext: {
+        schema: AgentSchema;
+        function?: string;
+    } | null;
+    history: {
+        function?: string;
+        maxHistoryChars?: number;
+    } | null;
+    tools: NormalizedAgentTool[];
+    events: AgentEventDeclaration[];
+}
+/**
+ * What the caller knows about each function a declaration may name: `null` (or
+ * absence from the map) is a function this app does not have. The CLI resolves
+ * it from the live listing overlaid by the function files this push selects;
+ * the admin routes from an app-scoped lookup.
+ */
+export type AgentFunctionFacts = Readonly<Record<string, AgentFunctionFact | null>>;
+/**
+ * What one function declares. `hasInputSchema`/`hasOutputSchema` are #3798's
+ * presence facts; `inputSchema`/`outputSchema` are #3799's — the stored value,
+ * a JSON string or an object, which `agentSchemaTranslationRefusals` translates
+ * for each of the agent's providers. Both schema fields are OPTIONAL, so a
+ * caller that only needs the presence half is unchanged (principle 5).
+ */
+export interface AgentFunctionFact {
+    hasInputSchema: boolean;
+    hasOutputSchema: boolean;
+    inputSchema?: unknown;
+    outputSchema?: unknown;
+}
+export interface AgentDeclarationInput {
+    /** `[prompt].kind`; unset means `chat`. */
+    kind?: unknown;
+    /** `[prompt.agent]`: a table, a JSON string encoding one, or unset. */
+    agent?: unknown;
+    /** `[prompt].outputSchema` — refused on an agent. */
+    outputSchema?: unknown;
+    /**
+     * The function facts. Omitted means "not known here": the file-decidable
+     * half runs alone (the CLI's `config diff` collector has no app state).
+     */
+    functions?: AgentFunctionFacts;
+}
+export type AgentDeclarationResolution = {
+    ok: true;
+    declaration: AgentDeclaration | null;
+} | {
+    ok: false;
+    refusals: AgentRefusal[];
+};
+/**
+ * The same label, for the sibling rules that refuse a declaration from their
+ * own module (#3799's `provider-schema.ts`), so every agent refusal points at
+ * the block the author wrote.
+ */
+export declare const AGENT_BLOCK_LABEL = "[prompt.agent]";
+/**
+ * The function keys a declaration references (tools, turn context, history),
+ * each once, in declaration order. What a caller resolves into the
+ * `functions` facts before calling the resolver. `[]` for a block that is
+ * absent or does not parse — the resolver refuses the latter itself.
+ */
+/**
+ * `[prompt.agent]` as a value: a table as it is, one JSON string parsed,
+ * `undefined` for absence or for anything that is not a JSON object (which
+ * `resolveAgentDeclaration` refuses on its own).
+ *
+ * Exported for the sibling rules that read the same block — #3799's
+ * `agentSchemaTranslationRefusals` — so a declaration written as one JSON
+ * string is read identically by every rule that consumes it.
+ */
+export declare function parseAgentDeclarationBlock(agent: unknown): Record<string, unknown> | undefined;
+export declare function agentDeclarationFunctionKeys(agent: unknown): string[];
+/**
+ * The one rule: is this `[prompt.agent]` declaration (with the prompt's kind
+ * and `outputSchema`) something the platform can run?
+ *
+ * `{ ok: true, declaration }` carries the AUTHORED value — parsed when the
+ * block was one JSON string, otherwise unchanged — or `null` for an absent
+ * block. Callers store exactly this.
+ */
+export declare function resolveAgentDeclaration(input: AgentDeclarationInput): AgentDeclarationResolution;
+/**
+ * The refusal of a single-shot run of an agent — `ctx.prompts.run`, the member
+ * execute route, the admin execute and preview routes, the workflow
+ * `prompt.execute` step and the executor itself (§D1: an agent runs turn by
+ * turn in a session, never once).
+ */
+export declare function agentNotRunnableRefusal(promptKey?: string): AgentRefusal;
+/**
+ * The refusal of an agent round asked of a prompt that is not an agent —
+ * #3800 (`PromptExecutionService.resolveAgentTurnConfig` and
+ * `executeAgentRound`). The mirror of `agentNotRunnableRefusal`.
+ */
+export declare function agentRoundNotAgentRefusal(promptKey: string): AgentRefusal;
+/**
+ * The refusal of a prompt test case that involves an agent (§D1: prompt test
+ * cases are refused for the kind in v1; multi-turn tests are deferred).
+ * `subject` is a case written ON the agent, `evaluator` a case that names the
+ * agent as its judge.
+ */
+export declare function agentTestCaseRefusal(promptKey: string, role: "subject" | "evaluator"): AgentRefusal;
+/**
+ * The declaration with every default applied: `answeredBy = "initiator"`, the
+ * platform maximums for the limits, and per tool `invoke = "request"` (server
+ * tools), `approval = false` and `historyScope = "session"`.
+ *
+ * The ONLY accessor for defaults — the stored value never carries them
+ * (DSO-3798-001). Takes a value `resolveAgentDeclaration` accepted (or `null`)
+ * and leaves it untouched.
+ */
+export declare function normalizeAgentDeclaration(declaration: AgentDeclaration | null | undefined): NormalizedAgentDeclaration;
+/**
+ * Meaning-preserving schema translation, per provider — issue #3799
+ * (project `agents`, §D6, intent criterion 2).
+ *
+ * A tool or event schema reaches a provider only through a translation that
+ * preserves its meaning; anything else is refused at push, naming the path, the
+ * keyword and the provider. The lossy `sanitizeSchemaForGemini` clean-up
+ * (`src/services/block-executor.ts`) is NOT reused here: it drops unions and
+ * references and rewrites a free-form object as a string, all of which change
+ * what the model may produce. It stays where it is, for chat output schemas
+ * (the project's non-goal: chat is unchanged).
+ *
+ * ## What "lossless" means (spec §3)
+ *
+ * Every keyword is either
+ *   (a) passed to the provider unchanged with the same meaning,
+ *   (b) rewritten into a provider spelling that admits exactly the same set of
+ *       values, or
+ *   (c) dropped because dropping it changes neither what the model is told it
+ *       may produce nor what the platform enforces on what it produced.
+ *
+ * Anything else is refused. The only silent drops are the annotations with no
+ * value meaning (`$schema`, `$id`, `$comment`) and `additionalProperties`
+ * (DSO-3799-001): Gemini's function `Schema` has no spelling for a closed
+ * object at all, the platform validates every tool argument against the
+ * ORIGINAL, untranslated schema (#3800, criterion 3) so an extra key becomes
+ * the structured error the model sees, and a model following `properties` is
+ * never told it may add keys. Refusing it instead would put the platform's own
+ * closed-object marker — `additionalProperties: false` is how
+ * `src/workflows/schema-descriptor.ts` spells a closed object — outside
+ * Gemini's reach.
+ *
+ * The TRANSLATED schema is what the provider is sent; the ORIGINAL is what the
+ * platform keeps and validates against. Neither function here mutates its
+ * input.
+ *
+ * ## The two providers
+ *
+ * - `openrouter` forwards `tools[].function.parameters` as JSON Schema to the
+ *   model's own upstream. The platform cannot know each upstream's dialect, so
+ *   the only honest translation is identity — nothing is refused.
+ * - `gemini` takes the OpenAPI 3.0 `Schema` object that
+ *   `functionDeclarations[].parameters` accepts: one `type` from a closed list,
+ *   `nullable`, `format` from a documented list, `enum` of strings,
+ *   `properties`/`required`, `items`, the numeric and length bounds,
+ *   `propertyOrdering`, `example`, and `anyOf`. It has no `$ref`, `oneOf`,
+ *   `allOf`, `not`, `const`, `additionalProperties`, type arrays or
+ *   `type: "null"`; an object needs non-empty `properties` and an array needs
+ *   `items`. Lowercase type names are accepted (the existing `responseSchema`
+ *   path already sends them).
+ *
+ * Pure and dependency-free, like every module under `src/config-surface/`, and
+ * vendored into the CLI artifact after `agent-declaration.ts` so the push
+ * preflight and the admin routes refuse exactly the same schemas.
+ */
+/** The providers a prompt config may name. */
+export type SchemaProvider = "openrouter" | "gemini";
+/** One untranslatable keyword: where it is, what it is, and why it cannot go. */
+export interface SchemaTranslationRefusal {
+    /**
+     * The dotted path from the schema root, with indexes — `properties.amount`,
+     * `items.properties.kind`, `anyOf[1].properties.x`. `""` is the root itself.
+     */
+    path: string;
+    /** The keyword that cannot be carried, as the author spelled it. */
+    keyword: string;
+    /** What the provider cannot express, and what to write instead. */
+    reason: string;
+}
+export type SchemaTranslation = {
+    ok: true;
+    schema: Record<string, unknown>;
+} | {
+    ok: false;
+    refusals: SchemaTranslationRefusal[];
+};
+/** What a message calls the root. */
+export declare function schemaPathLabel(path: string): string;
+/**
+ * Translate one schema for one provider, or refuse it naming every keyword it
+ * cannot carry.
+ *
+ * OpenRouter is identity — a deep copy of the input, so a caller that edits the
+ * result never reaches the stored original. Gemini follows the table in spec
+ * §4. Every refusal of one schema is returned at once, so an author fixes it in
+ * one pass (principle 6).
+ */
+export declare function translateSchemaForProvider(schema: unknown, provider: SchemaProvider | string): SchemaTranslation;
+/** One non-archived config of the prompt: which provider, under which name. */
+export interface AgentSchemaConfigFact {
+    configName: string;
+    provider: string;
+    /** The per-version status; `archived` is skipped (spec §3). */
+    status?: string | null;
+}
+export interface AgentSchemaTranslationInput {
+    /** `[prompt.agent]` as authored: a table, one JSON string encoding one, or unset. */
+    declaration: unknown;
+    /**
+     * What this app holds for each function the declaration names, including the
+     * schemas a server tool's two schemas come from. Omitted means "not known
+     * here" — server tools are then not checked, and the caller that does know
+     * checks them.
+     */
+    functions?: AgentFunctionFacts;
+    /** Every config of the prompt. Archived ones are skipped. */
+    configs: ReadonlyArray<AgentSchemaConfigFact>;
+}
+/**
+ * Every `AGENT_SCHEMA_NOT_TRANSLATABLE` refusal an agent's declaration owes,
+ * checked against the provider of every config that is not archived
+ * (intent criterion 2).
+ *
+ * One refusal per (schema, path, keyword, provider): it names the tool or
+ * event, which schema, the dotted path, the keyword, the provider, the config
+ * names on that provider, and the remedy. Two configs on the same provider
+ * produce ONE refusal naming both — the author's fix is the same either way.
+ *
+ * A declaration with no tools and no events reads no function schema at all.
+ */
+export declare function agentSchemaTranslationRefusals(input: AgentSchemaTranslationInput): AgentRefusal[];
+export declare const PROMPT_SURFACE: ConfigObjectSurface;
+export declare const INTEGRATION_SURFACE: ConfigObjectSurface;
+export declare const WEBHOOK_SURFACE: ConfigObjectSurface;
+export declare const CRON_TRIGGER_SURFACE: ConfigObjectSurface;
+export declare const BLOB_BUCKET_SURFACE: ConfigObjectSurface;
+/**
+ * The `email-template` configuration object's definition (issue #2644, phase 2).
+ *
+ * `email-templates/<emailType>.toml` carries a single `[template]` table. The
+ * object is an OVERRIDE of a built-in template: the detail response is
+ * `{ emailType, hasOverride, override: {...}, default: {...} }`, and only the
+ * `override` half is a field surface — the `default` half is what the platform
+ * ships. Both are declared as response-only keys so `config pull`'s
+ * unrecognized-key warning reports genuinely unknown fields rather than the
+ * envelope.
+ *
+ * There is one write endpoint (`PUT …/email-templates/{emailType}`, an upsert),
+ * so every field is writable on both modes.
+ */
+/**
+ * Email types RETIRED by #2884, kept named rather than simply deleted.
+ *
+ * Email sign-in sends ONE email from the `email-sign-in` template, so
+ * `magic-link` and `otp` are no longer rendered by any code path — which is
+ * what makes deleting the link block from an `email-sign-in` override an
+ * actual guarantee rather than a hope about which endpoint ran.
+ *
+ * A stored override for a retired type is NOT deleted: it stays listed and
+ * readable (labelled retired, with the guidance below) so an app can find its
+ * customization and migrate it, and deleting it still works. Everything that
+ * would author one — the admin write/preview/test endpoints, `config create`,
+ * a `config push --only` selector — refuses by name instead. Silent
+ * non-rendering is the outcome all of that exists to avoid.
+ *
+ * It lives in the config surface, not beside the default templates, because
+ * the CLI vendors this directory and needs the same sentence.
+ */
+export declare const RETIRED_EMAIL_TYPES: readonly ["magic-link", "otp"];
+export type RetiredEmailType = (typeof RETIRED_EMAIL_TYPES)[number];
+/** True when `emailType` is one of the retired sign-in types. */
+export declare function isRetiredEmailType(emailType: string): emailType is RetiredEmailType;
+/** What every surface says about a retired type, in one sentence. */
+export declare function retiredEmailTypeGuidance(emailType: string): string;
+export declare const EMAIL_TEMPLATE_SURFACE: ConfigObjectSurface;
+export declare const DATABASE_TYPE_SURFACE: ConfigObjectSurface;
+export declare const RULE_SET_SURFACE: ConfigObjectSurface;
+export declare const GROUP_TYPE_CONFIG_SURFACE: ConfigObjectSurface;
+export declare const COLLECTION_TYPE_CONFIG_SURFACE: ConfigObjectSurface;
+export declare const METADATA_CATEGORY_CONFIG_SURFACE: ConfigObjectSurface;
+/**
+ * The `transform` configuration object's definition (issue #2644, phase 3).
+ *
+ * Transforms are the one synced type with NO TOML field table: a transform is
+ * `transforms/<name>.rhai`, a Rhai source file, and its whole authored surface
+ * is the script body. `config pull` writes the active `ScriptConfig`'s body and
+ * `config push` sends it back; there is no key/value table to define, and the
+ * `Script` / `ScriptConfig` scalars around it (name, description, inputSchema,
+ * limits, status) are not authorable through the sync slot today.
+ *
+ * The entry exists so that is a DECISION rather than an absence. Criterion 3's
+ * registry guard reads `SYNC_RESOURCE_TYPES` and requires a surface per label;
+ * without this module `transform` would have to sit in an exemption list, which
+ * is precisely the "absent from a hand-written list" failure mode this epic
+ * exists to end.
+ */
+export declare const TRANSFORM_SURFACE: ConfigObjectSurface;
+export declare const SERVER_FUNCTION_SURFACE: ConfigObjectSurface;
+export declare const TEST_CASE_SURFACE: ConfigObjectSurface;
+export declare const APP_SETTINGS_SURFACE: ConfigObjectSurface;
+/**
+ * The configuration-object registry (issue #2644).
+ *
+ * `CONFIG_SURFACES` holds one entry per synced configuration object type. The
+ * registry — not a per-type test — is what makes coverage follow from existing:
+ * `cli/tests/unit/config-surface-drift-guard.test.ts` reads the CLI's
+ * `SYNC_RESOURCE_TYPES` labels and fails when a label has no surface here.
+ *
+ * `CONFIG_SURFACES` is the write authority. `SYNC_RESOURCE_TYPES` keeps its
+ * documented role — directory/state/prune/diff layout metadata, explicitly "not
+ * a write framework" — and gains no write-surface fields; the two are
+ * cross-checked, not merged.
+ */
+/**
+ * Every configuration object whose field surface is defined here.
+ *
+ * One entry per `SYNC_RESOURCE_TYPES` label, plus the two surfaces that
+ * round-trip without being a per-entity file: `app-settings` (`app.toml`) and
+ * `test-case` (`<key>.tests/`). Nothing that syncs sits outside the registry —
+ * `PENDING_MIGRATION`, the migration's temporary exemption list, is gone as of
+ * phase 3, so a new synced type has nowhere to be parked and fails the registry
+ * guard until it is defined (#2644 criterion 3).
+ */
+export declare const CONFIG_SURFACES: readonly ConfigObjectSurface[];
+/**
+ * The configuration surfaces that have not declared their CROSS-FIELD rules yet
+ * (#3373, project `cli-server-rule-parity`).
+ *
+ * A surface declares either `crossFieldRules` or `noCrossFieldRules`; one that
+ * declares neither is on this list, and the guard asserts the two sides agree in
+ * both directions. Unlike #2644's `PENDING_MIGRATION` — deleted once the field
+ * surfaces were all defined — this is not an exemption anyone may add to: it is
+ * a settled inventory of work, and it only ever SHRINKS.
+ *
+ * The ratchet: `cli/tests/unit/config-surface-rules-guard-3373.test.ts` carries
+ * its own literal copy of this list and asserts the two are equal. Every
+ * migration removes its label from BOTH in the same change — that shrink is part
+ * of the migrating issue's definition of done. Adding a label back here alone
+ * fails the guard; adding it back to both is an edit to the guard itself, which
+ * is as review-visible as weakening any other assertion.
+ */
+export declare const CROSS_FIELD_RULES_UNMIGRATED: readonly string[];
+/** The surface for a `SyncResourceType.label`, or undefined when unmigrated. */
+export declare function getConfigSurface(label: string): ConfigObjectSurface | undefined;
+/** One table of one surface, addressed by its TOML path. */
+export declare function getConfigTable(label: string, tomlPath: readonly string[]): ConfigTable | undefined;
+/**
+ * Every field of every `models.yaml` model a configuration-object definition
+ * names, in declaration order — the coverage guard's anchor (#2644 criterion 2).
+ */
+export declare const GENERATED_CONFIG_MODEL_FIELDS: Readonly<Record<string, readonly string[]>>;
+export {};