@alexkroman1/aai-cli 14.0.0 → 15.1.0

package/dist/_artifacts-BJOYGQPp.mjs

@@ -0,0 +1,21 @@
+#!/usr/bin/env node
+import path from "node:path";
+//#region src/_artifacts.ts
+/**
+* The `.aai/` layout — where `aai build` leaves what `aai start` and the
+* deployment targets read back.
+*
+* A LEAF module, and that is the whole reason it exists. These two paths were
+* declared where they were first needed (`build.ts`, `start.ts`), which was
+* fine while the readers were the writers. `_vercel-output.ts` needs both and
+* is imported BY `build.ts`, so taking them from there is an import cycle —
+* one Biome rejects, and one that would fail at runtime rather than at build
+* time, since a `const` read across a cycle is a `ReferenceError` decided by
+* import order. Both original homes re-export, so no published subpath moved.
+*/
+/** Where `aai build` leaves the worker bundle, relative to the project root. */
+const WORKER_ARTIFACT_REL = path.join(".aai", "worker.mjs");
+/** Where `aai build` leaves the built browser client, relative to the root. */
+const CLIENT_ARTIFACT_REL = path.join(".aai", "client");
+//#endregion
+export { WORKER_ARTIFACT_REL as n, CLIENT_ARTIFACT_REL as t };

package/dist/_artifacts.d.ts

@@ -0,0 +1,16 @@
+/**
+ * The `.aai/` layout — where `aai build` leaves what `aai start` and the
+ * deployment targets read back.
+ *
+ * A LEAF module, and that is the whole reason it exists. These two paths were
+ * declared where they were first needed (`build.ts`, `start.ts`), which was
+ * fine while the readers were the writers. `_vercel-output.ts` needs both and
+ * is imported BY `build.ts`, so taking them from there is an import cycle —
+ * one Biome rejects, and one that would fail at runtime rather than at build
+ * time, since a `const` read across a cycle is a `ReferenceError` decided by
+ * import order. Both original homes re-export, so no published subpath moved.
+ */
+/** Where `aai build` leaves the worker bundle, relative to the project root. */
+export declare const WORKER_ARTIFACT_REL: string;
+/** Where `aai build` leaves the built browser client, relative to the root. */
+export declare const CLIENT_ARTIFACT_REL: string;

package/dist/_build-target.d.ts

@@ -0,0 +1,172 @@
+/**
+ * Deployment TARGETS — what `aai build` emits beside the worker so a host can
+ * run this project without the project holding anything host-specific.
+ *
+ * ## Why a target rather than a file in the scaffold
+ *
+ * Every host wants a different entry shape: Vercel wants a module whose default
+ * export is an `http.Server` it binds itself, a container wants a long-lived
+ * process, another platform wants something else again. Committing one of those
+ * to the scaffold makes every project assert a fact that is load-bearing on
+ * exactly one host — the same objection that removed `server.mjs`.
+ *
+ * Nitro is the worked precedent: one codebase, a preset per provider, and the
+ * preset EMITS the host's expected shape into the build directory. `node-server`
+ * is its default and Vercel/Netlify/Cloudflare are detected from the CI
+ * environment with no configuration. Next does the same narrower thing with
+ * `output: "standalone"` — it generates a `server.js` rather than asking anyone
+ * to write one. Either way the user's repository contains no host file, which is
+ * the property to preserve here.
+ *
+ * ## Auto-detection, and why it is safe
+ *
+ * A target is chosen with `--target`, or detected from the environment when the
+ * flag is absent. Detection reads the variables the hosts set on their own build
+ * containers ({@link TARGET_ENV_MARKERS}), so it only ever fires where the build
+ * is genuinely running on that host — a laptop sets none of them and gets
+ * {@link DEFAULT_BUILD_TARGET}, which emits nothing extra and is what every
+ * existing project already does.
+ */
+/** The targets `aai build --target` accepts. */
+export declare const BUILD_TARGETS: readonly ["node", "vercel"];
+export type BuildTarget = (typeof BUILD_TARGETS)[number];
+/**
+ * What a build with no `--target` and no host environment produces: the worker
+ * and the client, and nothing else.
+ *
+ * `node` rather than a `"none"` sentinel because it NAMES the deployment it
+ * serves — a long-lived process running `aai start` — which is what every
+ * container platform wants and what the scaffold's own `start` script runs.
+ */
+export declare const DEFAULT_BUILD_TARGET: BuildTarget;
+/**
+ * The environment variable each host sets on its own build container.
+ *
+ * `VERCEL` is set for every Vercel build and deployment. Detection is per host
+ * rather than a single "am I in CI" test, because a GitHub Action building a
+ * container image is CI too and wants the default.
+ */
+export declare const TARGET_ENV_MARKERS: Readonly<Record<string, BuildTarget>>;
+export declare function isBuildTarget(value: string): value is BuildTarget;
+/**
+ * Resolve the target for this build: an explicit flag wins, then the
+ * environment, then {@link DEFAULT_BUILD_TARGET}.
+ *
+ * An unrecognised `--target` is REFUSED naming what is accepted, rather than
+ * falling back to the default — a typo'd target that silently built the default
+ * would deploy a project missing the entry its host needs, and the failure would
+ * arrive as a 404 from the platform rather than as an error from the build.
+ */
+export declare function resolveBuildTarget(explicit: string | undefined, env?: Record<string, string | undefined>): BuildTarget;
+/**
+ * Where a PREBUILT Vercel deployment lives, relative to the project root.
+ *
+ * The Build Output API rather than an `api/` entry plus a `vercel.json`, and
+ * the reason is ORDERING. Vercel reads `vercel.json` and decides what to build
+ * BEFORE it runs the build command, so a `vercel.json` that the build WRITES
+ * configures the NEXT deployment and not this one — a clean clone deploys with
+ * no rewrite and no function at all. The `api/` shape only ever appeared to
+ * work because a previous local `aai build --target vercel` had left both
+ * files in the working tree, which is a property of one laptop rather than of
+ * the repository. `.vercel/output/` is read AFTER the build command; it is the
+ * only place a build can describe its own deployment.
+ *
+ * Two more things fall out of owning the directory, both of which the `api/`
+ * shape got wrong and could not fix. The function bundle is ASSEMBLED here
+ * rather than traced, so `.aai/worker.mjs` — loaded through a dynamic
+ * `import(pathToFileURL(...))` that no static tracer can follow — and
+ * `.env.example` — the file that DECLARES which variables become `ctx.env` —
+ * are present because they were copied in. And the built client is served by
+ * the CDN out of `static/` instead of through the function.
+ *
+ * Nitro's vercel preset is the worked precedent and lands in exactly here:
+ * `output.dir = {{rootDir}}/.vercel/output`, `serverDir` a `.func` under it.
+ *
+ * @see https://vercel.com/docs/build-output-api/v3
+ */
+export declare const VERCEL_OUTPUT_DIR: string;
+/**
+ * The one function every request that is not a static file reaches.
+ *
+ * The Build Output API derives a function's ROUTE from its path, so the
+ * directory name IS a URL and must not collide with one the static output
+ * claims. **`index.func` collides**, which a deployment is the only way to
+ * find out: it is served at `/index`, and Vercel's directory index resolves
+ * `/` to the extensionless `/index` — so the function won `/`, every other
+ * asset came off the CDN correctly, and the home page 500'd on a deployment
+ * whose static output was perfect. Measured on a real preview:
+ * `/favicon.ico`, `/index.html` and both hashed `/assets/*` returned 200
+ * while `/` and `/index` did not.
+ *
+ * `__server` is Nitro's answer to the same problem (`__server.func`) and the
+ * reason is this one: a double-underscore prefix is not a path any bundler
+ * emits, so no static file can ever take the name.
+ */
+export declare const VERCEL_FUNCTION_DIR: string;
+/**
+ * The route {@link VERCEL_FUNCTION_DIR} is served at — its directory name
+ * without `.func`, which is how the Build Output API names a function.
+ */
+export declare const VERCEL_FUNCTION_ROUTE = "/__server";
+/** Static assets the Vercel CDN serves directly, never reaching the function. */
+export declare const VERCEL_STATIC_DIR: string;
+/** `nodejs<major>.x` for the Node running this build, clamped to what Vercel offers. */
+export declare function vercelNodeRuntime(version?: string): string;
+/**
+ * The Vercel function entry, emitted into {@link VERCEL_FUNCTION_DIR}.
+ *
+ * ## Why a `(req, res)` handler and not `export default server`
+ *
+ * `export default <http.Server>` is what Vercel's own `@vercel/node` BUILDER
+ * accepts, and it is the shape the previous `api/index.mjs` used. The Build
+ * Output API has no builder in the path: `launcherType: "Nodejs"` invokes the
+ * module's default export as a request handler, so the server never gets
+ * bound and there is nothing to raise an `upgrade` event on it.
+ *
+ * ## How a WebSocket survives that
+ *
+ * Vercel hands a Node function the raw upgrade through its PER-REQUEST
+ * context — `globalThis[Symbol.for("@vercel/request-context")].get()
+ * .upgradeWebSocket()` returns the `{ req, socket, head }` triple — rather
+ * than as an event. Nitro reaches it through `crossws/adapters/vercel`; here
+ * the adapter is three lines, because {@link AgentServer.node} is a real
+ * `http.Server` that already has both an `upgrade` and a `request` listener
+ * registered. Re-emitting onto it is the whole translation, and it means the
+ * deployed path through `server.ts` is the same one `aai dev` and `aai start`
+ * take — no second WebSocket entry point to keep in step.
+ *
+ * The `204` afterwards is what the launcher needs to consider the invocation
+ * finished; the socket the agent is now talking on is not this `res`.
+ *
+ * ## `import.meta.dirname`, not `process.cwd()`
+ *
+ * The function's working directory belongs to the platform, but `.aai/` and
+ * `.env.example` were copied in BESIDE this file. Resolving from the module
+ * keeps that a fact about the bundle rather than about how Vercel happens to
+ * invoke it.
+ */
+export declare const VERCEL_ENTRY_SOURCE = "// Generated by `aai build --target vercel` \u2014 do not edit, and do not commit.\n// Vercel invokes this handler per request and delivers a WebSocket upgrade\n// through its request context. See @alexkroman1/aai-cli/start.\nimport { createProjectServer } from \"@alexkroman1/aai-cli/start\";\n\nconst server = (await createProjectServer({ cwd: import.meta.dirname })).node;\n\nconst REQUEST_CONTEXT = Symbol.for(\"@vercel/request-context\");\n\nexport default function handler(req, res) {\n  if (req.method === \"GET\" && req.headers.upgrade?.toLowerCase() === \"websocket\") {\n    const upgrade = globalThis[REQUEST_CONTEXT]?.get?.()?.upgradeWebSocket?.();\n    if (upgrade) {\n      server.emit(\"upgrade\", upgrade.req, upgrade.socket, upgrade.head);\n      if (!res.headersSent && !res.writableEnded) {\n        res.statusCode = 204;\n        res.end();\n      }\n      return;\n    }\n  }\n  server.emit(\"request\", req, res);\n}\n";
+/**
+ * `.vc-config.json` — how the platform runs {@link VERCEL_ENTRY_SOURCE}.
+ *
+ * `supportsResponseStreaming` is not optional here: an agent streams TTS audio
+ * and SSE workflow events, and without it the platform buffers a response to
+ * completion, which for a stream that ends when the call does means it never
+ * arrives. `shouldAddHelpers` stays off — the entry speaks `node:http`, and
+ * the helpers exist to bolt Express-shaped sugar onto a handler that does not.
+ */
+export declare function vercelFunctionConfigSource(runtime?: string): string;
+/**
+ * `config.json` — the routing table, and the reason static assets stop paying
+ * for a function invocation.
+ *
+ * `{ "handle": "filesystem" }` serves anything present in
+ * {@link VERCEL_STATIC_DIR} from the CDN and only then falls through, so the
+ * client bundle, its assets and the worklets are edge-served while
+ * `/client-config`, `/websocket`, `/workflows/*` and the webhook route reach
+ * the agent. The `api/` shape routed EVERY request through the function, which
+ * this file's earlier revision noted as deliberate and "not what makes a
+ * deployment work or not" — true of correctness, false of cost, and free here
+ * because the Build Output API already separates the two directories.
+ */
+export declare const VERCEL_BUILD_CONFIG_SOURCE: string;

package/dist/{_bundler-DolUCMxu.mjs → _bundler-DM0d0M7m.mjs}

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 import { h as validateAgentExport } from "./_utils-D5JGcjiW.mjs";
-import { t as buildClient } from "./client-bundler-BJgREAh6.mjs";
+import { t as buildClient } from "./client-bundler-6mTLs6ny.mjs";
 import { buildWorker } from "./worker-bundler.mjs";
 import path from "node:path";
 import { pathToFileURL } from "node:url";

package/dist/{_dev-server-CSMqF8PN.mjs → _dev-server-BzWB6-4y.mjs}

@@ -1,21 +1,21 @@
 #!/usr/bin/env node
 import { i as outputSilenced, r as notify } from "./_ui-DCt4qZrk.mjs";
 import { a as errorCode, s as errorMessage$1 } from "./_utils-D5JGcjiW.mjs";
-import { n as fallbackHtmlPlugin } from "./client-bundler-BJgREAh6.mjs";
+import { n as fallbackHtmlPlugin } from "./client-bundler-6mTLs6ny.mjs";
 import { t as DEDUPED_PEERS } from "./_vite-env-kejF0p2L.mjs";
 import { buildWorker } from "./worker-bundler.mjs";
 import { typecheckProject } from "./typecheck.mjs";
 import { n as ensureApiKey } from "./_config-DYzC6WMD.mjs";
-import { n as createWorkerEvaluator } from "./_bundler-DolUCMxu.mjs";
-import { t as resolveServerEnv } from "./_server-common-vILJp3it.mjs";
+import { n as resolveServerEnv } from "./_server-common-De0haHr9.mjs";
+import { n as createWorkerEvaluator } from "./_bundler-DM0d0M7m.mjs";
 import { existsSync, statSync } from "node:fs";
 import path from "node:path";
 import { omitUndefined, plural } from "@alexkroman1/aai/utils";
 import { createCoalescingRunner, requestPath, sleep } from "@alexkroman1/aai/internal";
-import { agentConfigWarnings } from "@alexkroman1/aai/manifest";
 import { DEFAULT_LISTEN_HOST, WORKFLOW_API_PREFIX, createRuntime, createRuntimeServer, ensureSessionStateSchema, ensureWorkflowJournalSchema, requiredProviderEnvVars, withHostCredentialFallback } from "@alexkroman1/aai-runtime";
-import { WORKFLOW_DATA_DIR_ENV, consoleLogger, createMemoryJournal, handleWorkflowRequest, isPathInside, publishStepEnv } from "@alexkroman1/aai-runtime/internal";
 import { defaultClientDir } from "@alexkroman1/aai-ui/client-dir";
+import { agentConfigWarnings } from "@alexkroman1/aai/manifest";
+import { WORKFLOW_DATA_DIR_ENV, consoleLogger, createMemoryJournal, handleWorkflowRequest, isPathInside, publishStepEnv } from "@alexkroman1/aai-runtime/internal";
 import { watch } from "chokidar";
 import getPort, { portNumbers } from "get-port";
 import pDebounce from "p-debounce";
@@ -638,7 +638,10 @@ async function startDevServer(opts) {
 			env: hostModeEnv(providerEnv),
 			hostBaseAgent: agentDef,
 			greeting: agentDef.greeting,
-			...omitUndefined({ page: agentDef.page }),
+			...omitUndefined({
+				page: agentDef.page,
+				telephony: agentDef.telephony
+			}),
 			request: (req, res, url, method) => handleWorkflowRequest(req, res, url, method, {
 				deliver: () => runtime.deliverWorkflow,
 				logger: devLogger

package/dist/_e2e-test-utils.d.ts

@@ -61,7 +61,7 @@ export declare function waitForHealth(url: string, child?: ChildProcess, timeout
 export declare function waitForExit(child: ChildProcess, timeoutMs?: number): Promise<void>;
 /**
  * Run a scaffolded project the way a self-hoster does — `npm start`, which runs
- * the project's own `prestart` (`aai build`) and then `server.mjs`.
+ * the project's own `prestart` (`aai build`) and then `aai start`.
  *
  * Extracted because there are two legs now and the spawn is the fiddly half: the
  * port has to be read off stdout, and every way this can fail — a build error, a

package/dist/{_init-CQ8idAwo.mjs → _init-Bsi3DZNJ.mjs}

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import { d as readJson, g as writeJson, i as compareCodeUnits, u as isEexist } from "./_utils-D5JGcjiW.mjs";
 import { r as isDevMode, t as getMonorepoRoot } from "./_agent-BzUeqOdj.mjs";
-import { REPO_URL, downloadAndMergeTemplate } from "./_templates-CK4oKoeX.mjs";
+import { REPO_URL, downloadAndMergeTemplate } from "./_templates-CIlJ3Vay.mjs";
 import path from "node:path";
 import fs from "node:fs/promises";
 //#region src/_init.ts

package/dist/_server-common-De0haHr9.mjs

@@ -0,0 +1,70 @@
+#!/usr/bin/env node
+import { a as errorCode } from "./_utils-D5JGcjiW.mjs";
+import path from "node:path";
+import { parseEnv } from "node:util";
+import fs from "node:fs/promises";
+//#region src/_server-common.ts
+/**
+* One dotenv file's entries, or `{}` when it is not there.
+*
+* An ABSENT file is normal — `.env` is gitignored and a container usually ships
+* neither — while an UNREADABLE one is not: the agent would boot with no
+* secrets and fail later as an opaque provider auth error, so that one throws.
+*/
+async function readDotenv(file) {
+	try {
+		return parseEnv(await fs.readFile(file, "utf-8"));
+	} catch (err) {
+		if (errorCode(err) !== "ENOENT") throw err;
+		return {};
+	}
+}
+/**
+* The dotenv files a DEPLOYMENT reads, in precedence order.
+*
+* `.env.example` counts as a DECLARATION here and nowhere else, which is what
+* lets a container run with no `.env` at all: that file is committed, it names
+* the secrets the agent needs, and `docker run -e MY_API_KEY=...` supplies the
+* values — the shell always winning over a file entry, and a declared-but-empty
+* value being dropped rather than kept (see below). Without it a deployment
+* that ships no `.env` — which is every correctly-built image — resolves an
+* empty agent env and fails later as an opaque provider auth error.
+*
+* `aai dev` deliberately reads `.env` alone. There the developer HAS the file,
+* and treating the example as a declaration would surface a key they have not
+* filled in yet as one they have.
+*/
+const DEPLOY_ENV_FILES = [".env.example", ".env"];
+/**
+* Build the `ctx.env` record that agent tools will see at runtime.
+*
+* Only variables explicitly declared in `.env` are included — matching
+* the platform sandbox behavior where `ctx.env`
+* contains only secrets set via `aai secret put`. This prevents agents
+* from accidentally depending on shell-level vars (PATH, HOME, etc.) that
+* won't exist in production.
+*
+* Values are resolved by merging the `.env` file with the current
+* environment — existing shell exports take precedence over `.env`
+* defaults, without mutating `process.env`.
+*
+* @param cwd - Project directory containing `.env` (optional).
+* @param baseEnv - Override the environment to read values from (tests only).
+* @param files - Which dotenv files to read, later entries winning over
+*   earlier. Defaults to `.env` alone; {@link DEPLOY_ENV_FILES} is what a
+*   DEPLOYMENT reads, and its own doc says why the two differ.
+*/
+async function resolveServerEnv(cwd, baseEnv, files = [".env"]) {
+	const fileEntries = {};
+	const root = cwd;
+	if (root !== void 0) for (const file of files) Object.assign(fileEntries, await readDotenv(path.join(root, file)));
+	const source = baseEnv ?? process.env;
+	const env = {};
+	for (const [key, fileVal] of Object.entries(fileEntries)) {
+		const val = source[key] ?? fileVal;
+		if (val !== void 0 && val !== "") env[key] = val;
+	}
+	return env;
+}
+//#endregion
+export { resolveServerEnv as n, DEPLOY_ENV_FILES as t };

package/dist/_server-common.d.ts

@@ -1,3 +1,19 @@
+/**
+ * The dotenv files a DEPLOYMENT reads, in precedence order.
+ *
+ * `.env.example` counts as a DECLARATION here and nowhere else, which is what
+ * lets a container run with no `.env` at all: that file is committed, it names
+ * the secrets the agent needs, and `docker run -e MY_API_KEY=...` supplies the
+ * values — the shell always winning over a file entry, and a declared-but-empty
+ * value being dropped rather than kept (see below). Without it a deployment
+ * that ships no `.env` — which is every correctly-built image — resolves an
+ * empty agent env and fails later as an opaque provider auth error.
+ *
+ * `aai dev` deliberately reads `.env` alone. There the developer HAS the file,
+ * and treating the example as a declaration would surface a key they have not
+ * filled in yet as one they have.
+ */
+export declare const DEPLOY_ENV_FILES: readonly [".env.example", ".env"];
 /**
  * Build the `ctx.env` record that agent tools will see at runtime.
  *
@@ -13,5 +29,8 @@
  *
  * @param cwd - Project directory containing `.env` (optional).
  * @param baseEnv - Override the environment to read values from (tests only).
+ * @param files - Which dotenv files to read, later entries winning over
+ *   earlier. Defaults to `.env` alone; {@link DEPLOY_ENV_FILES} is what a
+ *   DEPLOYMENT reads, and its own doc says why the two differ.
  */
-export declare function resolveServerEnv(cwd?: string, baseEnv?: Record<string, string | undefined>): Promise<Record<string, string>>;
+export declare function resolveServerEnv(cwd?: string, baseEnv?: Record<string, string | undefined>, files?: readonly string[]): Promise<Record<string, string>>;

package/dist/{_templates-CK4oKoeX.mjs → _templates-CIlJ3Vay.mjs}

@@ -119,7 +119,7 @@ async function readJsonFile(file) {
 }
 /**
 * Directory holding the base scaffold — the files every project gets
-* underneath its template (package.json, tsconfig, `server.mjs`, …).
+* underneath its template (package.json, tsconfig, `.gitignore`, …).
 *
 * The scaffold is the single definition of the self-hosted entrypoint, so a
 * caller needing one of its files resolves it here rather than carrying a

package/dist/_templates.d.ts

@@ -37,7 +37,7 @@ type Manifest = Record<string, unknown>;
 export declare function mergeScaffoldManifest(existing: Manifest, scaffold: Manifest): Manifest | null;
 /**
  * Directory holding the base scaffold — the files every project gets
- * underneath its template (package.json, tsconfig, `server.mjs`, …).
+ * underneath its template (package.json, tsconfig, `.gitignore`, …).
  *
  * The scaffold is the single definition of the self-hosted entrypoint, so a
  * caller needing one of its files resolves it here rather than carrying a

package/dist/_vercel-output.d.ts

@@ -0,0 +1,63 @@
+/**
+ * Assemble a PREBUILT Vercel deployment — `.vercel/output/` — from what
+ * `aai build` just produced.
+ *
+ * The argument for the Build Output API over an `api/` entry is in
+ * `_build-target.ts` at {@link VERCEL_OUTPUT_DIR}; what this module adds is the
+ * consequence of it. A `.func` directory is a directory WE fill, so every file
+ * the server reads at runtime is present because it was copied in, and nothing
+ * depends on a static tracer following a path it structurally cannot:
+ *
+ * - **`.aai/worker.mjs`** is loaded through `import(pathToFileURL(...))`
+ *   (`start.ts`), which `@vercel/nft` cannot resolve. Under the `api/` shape
+ *   the build was green and the function 500'd on its first request with
+ *   "No built agent at .aai/worker.mjs".
+ * - **`.env.example`** is not documentation here. `resolveServerEnv` treats it
+ *   as the DECLARATION of which variables become `ctx.env` (see
+ *   `DEPLOY_ENV_FILES`), so a function without it hands every tool an empty
+ *   env while the Vercel project has the values set — a failure that looks
+ *   like a credential problem and is a packaging one.
+ * - **The client** is copied to `static/`, where the CDN serves it, and also
+ *   beside the worker, so `resolveClientDir` finds a real directory rather
+ *   than reaching into a `node_modules` that the bundle replaced.
+ *
+ * The entry is BUNDLED rather than shipped with a `node_modules`. Same call as
+ * the worker (`ssr: { noExternal: true }`, `root: cwd`), so it resolves the
+ * project's own installed SDK and pulls the runtime, `ws` and `pg` in with it
+ * — which is already the arrangement a deployed worker runs under, and it is
+ * what makes the function independent of whether the host's install left a
+ * usable, hoisted `node_modules` behind.
+ */
+/** Options for {@link emitVercelOutput}. */
+export interface EmitVercelOutputOptions {
+    /**
+     * Produce the function's `index.mjs`. Defaults to {@link bundleEntry}.
+     *
+     * Injectable so the ASSEMBLY — which file lands where, and which does not —
+     * can be asserted without a ~15s rolldown pass over the whole runtime. The
+     * bundle has its own contract and its own (scenario-tier) test; what this
+     * seam separates is a question about a directory from a question about a
+     * bundler.
+     */
+    bundle?: (cwd: string) => Promise<string>;
+}
+/**
+ * Write `.vercel/output/` for this project.
+ *
+ * The directory is REMOVED first. It is not addressed by content, so a
+ * function or a static asset left by an earlier build with a different shape
+ * would be deployed alongside this one — and `vercel deploy --prebuilt`
+ * uploads whatever is there.
+ */
+export declare function emitVercelOutput(cwd: string, options?: EmitVercelOutputOptions): Promise<void>;
+/**
+ * Bundle {@link VERCEL_ENTRY_SOURCE} and everything it imports into one ESM
+ * file.
+ *
+ * The entry is written INTO the project rather than a temp directory, because
+ * that is what makes `@alexkroman1/aai-cli/start` resolve against the user's
+ * install — the deployed server is then the version their lockfile pins, which
+ * is the same guarantee `aai publish` gives. Removed in a `finally`: a build
+ * that throws must not leave a file that looks authored.
+ */
+export declare function bundleEntry(cwd: string): Promise<string>;