primitive-admin 1.1.0-alpha.75 → 1.1.0-alpha.76

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

@@ -579,39 +579,47 @@ export declare const RETIRED_CONFIG_KEYS: Record<string, Record<string, RetiredC
 /** 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 database capability grammar for server functions (#3182, project
- * `server-functions` phase 2 of the intent, phase 1 of this child).
+ * The capability grammar for server functions — #3182 phase 1, rewritten by
+ * #3279 (project `server-functions` phase 3).
  *
- * A function declares what it may reach in its own TOML:
+ * A function declares in its own TOML what it may CONFIGURE:
  *
- *   capabilities = ["database:orders/order:read", "database:orders/order:write"]
- *   unscopedReads = true
+ *   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 ────────────────────────────────────
  *
- * The intent decides ("What does the database name in a grant refer to?") that
- * a grant names the database TYPE key, and the design fixes the string as
- * `database:<databaseType>/<modelName>:read|write` with no wildcards. That
- * string has to be INJECTIVE — one string, one (type, model, access) triple —
- * or a grant means two things at once. It is not injective for the identifiers
- * the repository accepts today: `database-type-config-controller.ts` forbids
- * only `#` in a type key, and js-bao's TOML loader preserves model names
- * verbatim, so `(type "a", model "b/c")` and `(type "a/b", model "c")` both
- * spell `database:a/b/c:read` (D3182-001).
- *
- * The fix is a charset rather than an escaping scheme: both components must
- * match `[A-Za-z0-9_-]+`, so neither delimiter can enter a component and the
- * grammar is injective by construction. Authored TOML stays readable, and a
- * database type whose key carries a delimiter is simply UNREACHABLE from
- * functions — fail closed, with an error that says why rather than a grant
- * that quietly covers a neighbour.
+ * 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 ──────────────────────────────────────────────
  *
- * Grants 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
+ * 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.
@@ -621,117 +629,120 @@ 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 whole grammar, in one expression. */
-export declare const DATABASE_GRANT_PATTERN: RegExp;
-export type GrantAccess = "read" | "write";
 /**
- * The families a grant may name, in the order the guidance lists them.
- *
- * Two shapes, not one:
- *
- *   KEYED  `integration:<key>`, `prompt:<key>`, `secret:<NAME>`, `var:<NAME>`
- *          — one component under {@link GRANT_COMPONENT_PATTERN}, naming a
- *          single object. Every key format the platform issues fits: an
- *          integration or prompt key is `^[a-z0-9][a-z0-9-_]{2,}$` and a
- *          secret or config-var name is `^[A-Z][A-Z0-9_]{0,63}$`.
- *   EXACT  `users:send`, `connections:send` — no key component at all. The
- *          design doc spells them this way, and the capability really is
- *          app-wide: a send names its target at CALL time, so there is no
- *          object for the grant to name.
- *
- * `database:` keeps its own two-component grammar, unchanged.
- *
- * `var:` is this child's choice (D3183-001). The intent is silent on config
- * vars; the family is named after the `{{vars.*}}` template namespace the
- * integration proxy already resolves, so an author who has written
- * `{{vars.REGION}}` reads `var:REGION` without learning a second word for the
- * same thing.
+ * 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", "prompt", "secret", "var"];
+export declare const KEYED_GRANT_FAMILIES: readonly ["integration", "secret"];
 /**
- * Whole platform capabilities — #3187, project `server-functions` phase 4.
- *
- * The EXACT shape, for the same reason the sends take it: neither names an
- * object. An app has ONE hourly email budget and ONE analytics dataset, so a
- * grant carrying a target would be a promise the enforcement point could not
- * keep.
- *
- * Both gate a function-principal-only route (`emails/send`,
- * `analytics/write-for-user`) rather than a family the gateway passes a
- * caller's own authority through. `email.send` has no HTTP route for a member
- * to call at all, and `analytics.writeForUser` is system-only by design
- * (D3187-SO-001) — caller-mode family admission cannot reach either, which is
- * why they are grants and not passthrough.
+ * 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 PLATFORM_CAPABILITIES: readonly ["email:send", "analytics:writeForUser"];
-export declare const EXACT_GRANT_STRINGS: readonly ["users:send", "connections:send", "email:send", "analytics:writeForUser"];
-export type GrantFamily = "database" | (typeof KEYED_GRANT_FAMILIES)[number] | "users" | "connections" | "email" | "analytics";
-export interface DatabaseGrant {
-    databaseType: string;
-    modelName: string;
-    access: GrantAccess;
-    /** The authored string, so an error can quote what was written. */
-    raw: string;
-}
+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 for the reason
- * {@link ParsedCapabilities} already gives: this module is vendored into the
- * CLI, which compiles with `strict: false`, so a caller reads `family` and
- * then the field that family populates, and the fields another family would
- * have used are simply absent.
+ * 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, prompt key,
-     * secret name or config-var name. EMPTY for `database:` (which carries its
-     * own two components) and for the exact send strings (which name nothing).
+     * 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;
-    /** `database:` only. */
-    databaseType?: string;
-    modelName?: string;
-    access?: GrantAccess;
     /** The authored string, so an error or a log line can quote it. */
     raw: string;
 }
-export interface ParsedGrant {
-    grant?: DatabaseGrant;
-    error?: string;
-}
 export interface ParsedFunctionGrant {
     grant?: FunctionGrant;
     error?: string;
 }
 /**
- * The grant string for a (type, model, access) triple, or null when either
- * identifier is outside the charset — which is the whole of "unreachable from
- * functions". Callers that hold real identifiers (the enforcement path, the
- * typed-handle emitter) use this rather than string concatenation, so no code
- * path can mint a string this module would not parse back to the same triple.
+ * 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 function formatDatabaseGrant(databaseType: string, modelName: string, access: GrantAccess): string | null;
+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;
+}
 /**
- * One capability entry as ANY grant, or the reason it is not one.
+ * A channel NAME, and its namespace.
  *
- * 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 families' shapes to try. Every diagnosis is
- * family-specific — an author who mistypes an access verb should not be told
- * to read a charset rule, and an author who hits the charset rule should be
- * told that the identifier, not their typing, is the problem.
+ * 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 parseFunctionGrant(entry: unknown): ParsedFunctionGrant;
+export declare function parseChannelName(value: unknown): ParsedChannelName;
 /**
- * One capability entry as a DATABASE grant, or the reason it is not one.
+ * One capability entry as a grant, or the reason it is not one.
  *
- * Kept as its own function because the `database:` grammar has two components
- * and an access verb, and saying which of the three went wrong is most of
- * what makes the error useful.
+ * 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 parseDatabaseGrant(entry: unknown): ParsedGrant;
+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
@@ -742,30 +753,32 @@ export interface ParsedCapabilities {
     ok: boolean;
     /** Deduped, in authored order — what the config row stores. Empty when refused. */
     capabilities: string[];
-    /**
-     * DATABASE grants only, and deliberately so.
-     *
-     * #3182's call sites — the DO envelope, the typed handle, the records
-     * decision, the unscoped-read rule — all read this field and all mean
-     * "database". Widening it in place would have handed every one of them five
-     * families it has no branch for, silently. The new families arrive beside
-     * it in {@link allGrants}, so a caller that wants them asks for them.
-     */
-    grants: DatabaseGrant[];
-    /** Every grant, all families, in authored order. */
+    /** Every grant, in authored order. */
     allGrants: FunctionGrant[];
     /**
-     * The whole platform capabilities (#3187), in authored order.
-     *
-     * The same family projection {@link grants} is for databases: the gateway
-     * asks "which platform capabilities does this version hold" and gets exactly
-     * those strings, without filtering a mixed list itself.
+     * 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.
      */
-    platformGrants: string[];
-    hasReadGrant: boolean;
+    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.
  *
@@ -773,65 +786,16 @@ export interface ParsedCapabilities {
  * 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): ParsedCapabilities;
-/**
- * The unscoped-read rule, from the intent's database-authorization decision:
- * "a member-accessible function whose database read has no `$caller` binding
- * needs an explicit unscoped-read flag in its config, and that flag is the
- * human-reviewed artifact. From phase 2, any member-reachable function holding
- * a database read grant carries the flag."
- *
- * Every HTTP-invocable function is member-reachable behind its access gate, and
- * in this phase every function is HTTP-invocable, so the rule applies to every
- * config declaring a read grant — a fail-closed superset of the intent's rule,
- * which a later child may narrow for trigger-only functions.
- */
-export declare function unscopedReadsRefusal(grants: readonly DatabaseGrant[], unscopedReads: boolean): string | null;
+export declare function parseCapabilities(value: unknown, options?: ParseCapabilitiesOptions): ParsedCapabilities;
 /**
- * What the two enforcement points know about one database type: the models its
- * schema declares, or that it declares no schema, or that the schema it does
- * declare could not be read.
- *
- * The third state is the reason this is an interface rather than a bare
- * `models` field. "No schema" and "a schema nobody can parse" are not the same
- * fact, and collapsing them makes an unparseable schema authorize every model
- * name an author cares to write (SO3182-001) — the widest possible answer to a
- * question the platform failed to evaluate.
- */
-export interface KnownGrantTargetType {
-    /** Model names the schema declares, or null when it declares no schema. */
-    models: ReadonlySet<string> | null;
-    /** True when a stored/authored schema exists but could not be parsed. */
-    schemaUnreadable?: boolean;
-}
-/**
- * What a grant may name: a database type the app has, and — when that type
- * declares a schema — a model the schema declares.
- *
- * `models: null` is a type with NO schema. The DatabaseDO is schemaless, so a
- * grant on such a type is accepted by grammar and simply carries no typed
- * handle; refusing it would make an untyped database ungrantable.
+ * The config-tree objects an `integration:` grant may name.
  *
- * `schemaUnreadable` is the opposite case and fails CLOSED: the type declares a
- * schema, the platform could not evaluate the grant against it, and an
- * authorization question that could not be evaluated is answered no.
- *
- * The map is supplied by the caller because the two enforcement points read
- * different sources for the same facts — the CLI reads the config tree's
- * `database-type-configs/*.toml`, the server reads the app's rows — and the
- * RULE is what must not differ.
- */
-export declare function validateGrantsAgainstTypes(grants: readonly DatabaseGrant[], types: ReadonlyMap<string, KnownGrantTargetType>): string[];
-/**
- * The config-tree objects an `integration:` or `prompt:` grant may name.
- *
- * Only the two families whose targets are CONFIG-TREE state. `secret:` and
- * `var:` are absent on purpose (D3183-002): their 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. `users:send` and
- * `connections:send` name no object.
+ * 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
@@ -842,11 +806,9 @@ export declare function validateGrantsAgainstTypes(grants: readonly DatabaseGran
 export interface KnownGrantTargets {
     /** Non-archived integration keys, or null when unknown. */
     integrations: ReadonlySet<string> | null;
-    /** Non-archived prompt keys, or null when unknown. */
-    prompts: ReadonlySet<string> | null;
 }
 /**
- * Grants naming an integration or prompt the app does not have.
+ * 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
@@ -868,23 +830,20 @@ export declare function validateKeyedGrantsAgainstTargets(grants: readonly Funct
  *
  * ── What the manifest is for ─────────────────────────────────────────────
  *
- * Two things, and neither is authorization at runtime:
- *
- *   1. **The read rule.** The intent's database-authorization decision says
- *      "from phase 4 a recorded `$caller` binding on every read satisfies the
- *      [unscoped-read] rule instead". That decision is made ONCE, at push, by
- *      a human-reviewable statement — which is exactly what a manifest is.
- *   2. **Observability.** `primitive functions get` and the admin get list
- *      what a version registered, so an operator can see it without reading
- *      the bundle (principle 8).
+ * 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,
- * the raw-read refusal and cache verification all happen in the platform-owned
- * SDK inside the isolate, and the grants remain the adversarial boundary. What
- * the manifest buys is protection against BUGS, which is the bound the design
- * doc states and this comment repeats so nobody has to rediscover it.
+ * 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 ──────────────────────────────────────────────
  *
@@ -893,11 +852,23 @@ export declare function validateKeyedGrantsAgainstTargets(grants: readonly Funct
  * 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. */
-export declare const FUNCTION_MANIFEST_SCHEMA_VERSION = 1;
+/**
+ * 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;
     caller?: boolean;
@@ -918,6 +889,21 @@ export interface ManifestQuery {
 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;
@@ -932,40 +918,6 @@ export interface ParsedManifest {
  * and whether the author meant any of it are questions this cannot answer.
  */
 export declare function parseFunctionManifest(value: unknown): ParsedManifest;
-/**
- * The phase-4 relaxation of the unscoped-read rule, from the intent: "from
- * phase 4 a recorded `$caller` binding on every read satisfies the rule
- * instead".
- *
- * Returns the refusal, or null when the config may be pushed without
- * `unscopedReads = true`.
- *
- * Fail-closed in three ways, each of which is a way an author could otherwise
- * get the flag waived without the property it stands for:
- *
- *   - no manifest at all is no evidence, so the flag is still required;
- *   - a manifest naming NO query that touches a read-granted model records
- *     nothing about how those models are read, so it satisfies nothing;
- *   - one non-caller-scoped registration over a read-granted model is enough
- *     to require the flag, because that query reads every row for every
- *     caller — which is exactly what the flag declares.
- */
-export declare function callerScopedReadsRefusal(grants: readonly DatabaseGrant[], unscopedReads: boolean, manifest: FunctionManifest | null): string | null;
-/**
- * Whether a running version's raw (non-query) reads must be refused inside the
- * sandbox — #3187 behavior 23.
- *
- * True exactly when the version was accepted under the relaxation: it holds a
- * database READ grant and did not declare `unscopedReads`. Such a version was
- * pushed on the strength of its manifest saying every read is caller-scoped,
- * so the SDK admits the caller-scoped registered reads and refuses the rest.
- *
- * Honest-code protection at the design doc's stated adequacy: the SDK is
- * platform-owned, but a hostile bundle is not obliged to use it. The gateway
- * and DatabaseDO grant checks (#3182) are unchanged and remain the adversarial
- * boundary.
- */
-export declare function callerScopedReadsRequired(capabilities: readonly string[], unscopedReads: boolean): boolean;
 export declare const WORKFLOW_SURFACE: ConfigObjectSurface;
 export declare const PROMPT_SURFACE: ConfigObjectSurface;
 export declare const INTEGRATION_SURFACE: ConfigObjectSurface;