@alexkroman1/aai-cli 9.2.0 → 10.0.0

package/dist/worker-bundler-CCVEDjm1.mjs

@@ -1,650 +0,0 @@
-#!/usr/bin/env node
-import { i as errorCode } from "./_utils-B8QmtFhK.mjs";
-import { n as withPreservedNodeEnv } from "./_vite-env-BNveawd1.mjs";
-import { builtinModules } from "node:module";
-import path from "node:path";
-import fs from "node:fs/promises";
-import { build } from "vite";
-import { BaseBuilder, applySwcTransform, detectWorkflowPatterns, shouldTransformFile } from "@workflow/builders";
-//#region _workflow-scan.ts
-/**
-* What the BUILT flow bundle carries — the two scans that read it, and the
-* checks over them.
-*
-* Split out of `workflow-bundler.ts` when that file crossed the 500-line cap,
-* along the seam the two scans already share: both read the same artifact after
-* the builder has written it, both attribute a line to a module through
-* esbuild's `// <path>` headers, and neither has anything to do with
-* CONFIGURING the build. One of them fails the build (a `require` the workflow
-* VM cannot answer) and the other warns (a call that replays differently), which
-* is the only real difference between them.
-*
-* Internal: `workflow-bundler.ts` is the surface the studio and the CLI's own
-* build call, and it re-exports nothing from here that they need.
-*
-* @module _workflow-scan
-*/
-/**
-* Every Node builtin, in both spellings esbuild can emit for one.
-*
-* `node:child_process` and bare `child_process` are the same module and the
-* bundle may name it either way — a bare name only reaches the output when the
-* source imported it bare, which npm is still full of.
-*/
-const RUNTIME_MODULES = /* @__PURE__ */ new Set([...builtinModules, ...builtinModules.map((name) => `node:${name}`)]);
-/**
-* A `require(…)` CALL, excluding esbuild's own `__require` shim.
-*
-* The lookbehind is what separates the two: `__require` is the shim esbuild
-* writes for a bundled CJS module's dynamic requires, and the STEP bundle
-* defines a real `require` for it (see {@link STEP_REQUIRE_SHIM}). A bare
-* `require` in the FLOW bundle is the different thing this scan is for.
-*/
-const REQUIRE_CALL = /(?<![\w$.])require\(\s*"([^"]+)"\s*\)/g;
-/** esbuild's per-module header — `// node_modules/pkg/index.js`, and nothing else. */
-const MODULE_COMMENT = /^\/\/ (\S+\.[cm]?[jt]sx?)$/;
-/**
-* The bundle's lines, each already attributed to the module esbuild's last
-* `// <path>` header named (undefined before the first one). Header lines are
-* consumed rather than yielded — no scan has anything to say about them.
-*
-* Both scans below walk the bundle exactly this way; sharing the walk is what
-* keeps "how a line is attributed" one answer rather than two copies that can
-* disagree.
-*/
-function* attributedLines(workflowCode) {
-	let module;
-	for (const line of workflowCode.split("\n")) {
-		const header = MODULE_COMMENT.exec(line.trim());
-		if (header) {
-			module = header[1];
-			continue;
-		}
-		yield {
-			line,
-			module
-		};
-	}
-}
-/**
-* The dedupe key for one finding — what was found, and where.
-*
-* A NUL separates the two halves (neither can contain one, so the key cannot
-* collide) and is spelled as an ESCAPE, never the raw byte: one control
-* character makes a file binary to `git grep`, and every ratchet here is a
-* `git grep`. See "Never write a control character" in AGENTS.md.
-*/
-function siteKey(found, module) {
-	return `${found}\u0000${module ?? ""}`;
-}
-/**
-* Find the Node builtins a flow bundle would `require` at load.
-*
-* The flow bundle is compiled in a `node:vm` `Script` whose context has
-* `module` and `exports` and **no `require`**, so one of these is a run that
-* dies at replay with `ReferenceError: require is not defined` — never a build
-* failure, and never a symptom before the first run. The WDK's own builder
-* bundles everything for exactly this reason and carries
-* `createNodeModuleErrorPlugin` to reject a builtin import at build time.
-*
-* That plugin has two blind spots this scan covers, and both are the DEPLOYED
-* shape rather than an exotic one:
-*
-* - It reports a violation only when it can point at the import LINE in a
-*   first-party file, matched with a single-line regex — so a multi-line
-*   `import {\n  x,\n} from "pkg"` finds nothing and the builtin is marked
-*   external in silence.
-* - It resolves that file against `process.cwd()`, which is not the project
-*   being built when the studio builds a workspace, so the read fails and the
-*   same silent path is taken.
-*
-* Both were reproduced. What reaches the VM either way is
-* `var import_node_child_process = require("node:child_process");` at the top
-* of the bundle, i.e. every run of every workflow in the project fails, and the
-* stack names a line of generated code inside a dependency.
-*
-* Restricted to builtin specifiers deliberately: those are the only ones this
-* builder leaves external (it marks nothing else so, precisely so nothing can
-* need a `require`), and a narrow set is what keeps the scan from reading the
-* text of a prompt as a violation.
-*
-* @internal
-*/
-function findVmRequires(workflowCode) {
-	const found = [];
-	const seen = /* @__PURE__ */ new Set();
-	for (const { line, module } of attributedLines(workflowCode)) for (const [, specifier] of line.matchAll(REQUIRE_CALL)) {
-		if (specifier === void 0 || !RUNTIME_MODULES.has(specifier)) continue;
-		const key = siteKey(specifier, module);
-		if (seen.has(key)) continue;
-		seen.add(key);
-		found.push({
-			specifier,
-			module
-		});
-	}
-	return found;
-}
-/**
-* Calls whose answer differs between a run and its replays, and what to say
-* about each.
-*
-* **A workflow body REPLAYS from the top on every resume** — after a `sleep`,
-* after a redeploy, after the container was reclaimed — and only a step's
-* result is journaled. So a body that reads the clock gets a different time on
-* every pass, and a body that fetches performs the request again, both silently:
-* the run completes, and its output is built from values that disagree with the
-* ones the earlier passes saw. The scaffold guide has always carried this rule
-* with the words "all of which fail silently if broken", and nothing checked it.
-*/
-const REPLAY_UNSAFE = [
-	{
-		re: /(?<![\w$.])Date\.now\s*\(/g,
-		fix: "reads a different clock on every replay — take the time in a `\"use step\"` body, whose result is journaled"
-	},
-	{
-		re: /(?<![\w$.])new Date\s*\(\s*\)/g,
-		fix: "reads a different clock on every replay — take the time in a `\"use step\"` body, whose result is journaled"
-	},
-	{
-		re: /(?<![\w$.])Math\.random\s*\(/g,
-		fix: "draws a different number on every replay — draw it in a `\"use step\"` body"
-	},
-	{
-		re: /(?<![\w$.])crypto\.randomUUID\s*\(/g,
-		fix: "mints a different id on every replay — mint it in a `\"use step\"` body"
-	},
-	{
-		re: /(?<![\w$.])fetch\s*\(/g,
-		fix: "runs again on every replay, and the VM has no fetch to run it with — call `stepFetch` from a `\"use step\"` body"
-	}
-];
-/**
-* Replay-unsafe calls the flow bundle carries, attributed to the project's OWN
-* `workflows/` files.
-*
-* Attribution is the whole design. The bundle inlines every non-external
-* dependency a workflow module imports — zod, a markdown parser, whatever — and
-* third-party code is full of `Date.now()` on paths a workflow never reaches, so
-* a scan of the bundle's text reports a library and blocks a correct project.
-* esbuild writes a `// <path>` header per module (the same one
-* {@link findVmRequires} reads), so lines can be charged to the file they were
-* written in, and only the project's own workflow sources are read.
-*
-* Scanning the BUNDLE rather than the sources is what makes a `"use step"` body
-* exempt for free: the workflow-mode transform has already removed them, so
-* what is left is the part that really does replay.
-*
-* @internal
-*/
-function findReplayUnsafeCalls(workflowCode) {
-	const found = [];
-	const seen = /* @__PURE__ */ new Set();
-	for (const { line, module } of attributedLines(workflowCode)) {
-		if (module === void 0 || !isProjectWorkflowModule(module)) continue;
-		for (const { re, fix } of REPLAY_UNSAFE) for (const [call] of line.matchAll(re)) {
-			const key = siteKey(call, module);
-			if (seen.has(key)) continue;
-			seen.add(key);
-			found.push({
-				call,
-				fix,
-				module
-			});
-		}
-	}
-	return found;
-}
-/**
-* Is this bundled module one of the project's own `workflows/` files?
-*
-* A dependency's path runs through `node_modules/`, which is excluded first so
-* a package that happens to live in a directory called `workflows` cannot be
-* read as the project's.
-*/
-function isProjectWorkflowModule(module) {
-	const posix = module.split(path.sep).join("/");
-	return !posix.includes("node_modules/") && /(?:^|\/)workflows\//.test(posix);
-}
-/**
-* The warning `aai build` and `aai dev` print for a replay-unsafe call.
-*
-* A WARNING and not a build failure, deliberately. The attribution above makes
-* the scan accurate about which FILE a call is in, and it cannot know whether a
-* plain function in a `workflows/` module is reached from a body (where the
-* rule bites) or only from a step (where it does not) — so the one thing it
-* must not do is refuse a correct project. A silent build was the actual
-* problem; a line naming the file solves it without that risk.
-*/
-function replayWarnings(workflowCode) {
-	return findReplayUnsafeCalls(workflowCode).map(({ call, fix, module }) => `${module}: \`${call}…\` ${fix}.`);
-}
-/**
-* Fail the build when the flow bundle carries a `require` — see
-* {@link findVmRequires} for what that means and why nothing upstream catches it.
-*
-* The message has to name the MODULE as well as the specifier, because the
-* import that caused it is not in the file an author is looking at: only a
-* `"use step"` body is stripped from this bundle, so a value a `workflows/`
-* module holds at module scope — an exported helper, a constant — keeps its
-* import, and that import's whole graph rides into the VM.
-*/
-function assertNoVmRequires(workflowCode) {
-	const sites = findVmRequires(workflowCode);
-	if (sites.length === 0) return;
-	const lines = sites.map(({ specifier, module }) => `  ${specifier}${module === void 0 ? "" : ` — from ${module}`}`);
-	throw new Error([
-		`This project's workflows cannot run: the workflow bundle requires ${sites.length === 1 ? "a Node module" : "Node modules"} that the workflow VM has no \`require\` for.`,
-		...lines,
-		"",
-		"Only a `\"use step\"` body is removed from this bundle, so anything a `workflows/` module holds at MODULE scope keeps its import — including an exported helper that a step body is the only caller of. Move that use inside the step body, or into a module only a step body imports."
-	].join("\n"));
-}
-//#endregion
-//#region workflow-bundler.ts
-/**
-* Workflow bundling — turning a project's `workflows/` directory into the two
-* small artifacts a guest needs to run durable workflows.
-*
-* Public (no `_` prefix) for the same reason as `worker-bundler.ts`: the studio
-* builds its workspaces through this too, so a workflow published from the
-* browser comes out of the same pass as one from `aai build`.
-*
-* @internal — build hook for aai-server/the studio; not a supported public API
-* and not covered by semver.
-*
-* ## Why this exists at all
-*
-* The Workflow Development Kit's own integrations (Next, Nitro, SvelteKit) build
-* workflow routes while building the SERVER, by scanning `workflows/` and
-* emitting handler files. That model does not fit this platform: the guest image
-* is baked once and then serves MANY tenants' agents, each arriving over
-* `bundle/load` at runtime. There is no `workflows/` directory in existence when
-* the harness is built. So the transform has to happen per tenant at deploy
-* time — here — and the guest receives the result as data.
-*
-* ## The two artifacts, and why they are small
-*
-* A default `workflow build` emits a 3.7 MB flow bundle and a 12 MB step bundle,
-* because each one inlines the whole WDK runtime. Neither could ride the guest's
-* single-ESM-string delivery. Two settings fix that, and both are load-bearing:
-*
-* - **`externalPackages: ["workflow", …]`** — the WDK is resolved from the
-*   guest's BAKED image instead of being inlined. Step bundle: 12 MB → ~7 KB.
-* - **`bundleFinalOutput: false`** — skips wrapping the workflow-mode code in a
-*   runtime host, which is exactly what `workflowEntrypoint(code)` supplies
-*   itself at the other end. Dialog bundle: 3.7 MB → ~69 KB.
-*
-* So `workflowCode` is passed to `workflowEntrypoint()` in the guest and
-* `stepCode` is evaluated there to register its step functions.
-*
-* ## The THIRD transform, which is the agent bundle's
-*
-* Those two are what the queue runs. The agent bundle needs a third —
-* `applySwcTransform(…, "client")`, wired in as {@link workflowClientPlugin} —
-* and without it the whole mechanism is inert: `ctx.workflows.start` reads the
-* `workflowId` the compiler attaches to a directive body, and Vite bundling
-* `workflows/research.ts` the ordinary way attaches nothing. The symptom is
-* `MISSING_WORKFLOW_ID_MESSAGE` at the first `start()` — an agent that builds,
-* deploys, boots and answers the phone, and cannot start a run.
-*
-* The plugin transforms EXACTLY the files the builder scanned (`inputFiles`),
-* not "every file with a directive". Same list, same `moduleSpecifierRoot`,
-* therefore the same ids by construction — a body outside `workflows/` cannot
-* acquire an id that no flow bundle registered, which would trade a clear
-* failure at `start()` for a run that enqueues and then fails at replay.
-*
-* ## Config details that are not optional
-*
-* Each of these cost real time to find, and none fails in a way that names
-* itself:
-*
-* - `dirs` must carry the `./` prefix. A bare `"workflows"` crashes inside
-*   enhanced-resolve with `Cannot read properties of undefined (reading
-*   'length')` from `join(undefined, …)`, nowhere near the cause.
-* - Every bundle path must be ABSOLUTE, for the same reason.
-* - `projectRoot` and `moduleSpecifierRoot` must be set explicitly; they do not
-*   default to `workingDir` on the path this takes.
-* - `keepInterimBundleContext` must stay off — it leaves an esbuild watch context
-*   alive, so a one-shot build never exits.
-*/
-/**
-* The directory a project's `"use workflow"` bodies live in.
-*
-* The WDK builder's convention, not ours, and it is why a workflow body cannot
-* live in `agent.ts`: only files under here are transformed. A body outside it
-* runs inline, once, with no durability and nothing reporting that.
-*/
-const WORKFLOWS_DIR = "workflows";
-/**
-* Packages left OUT of both bundles, resolved from the guest's baked image.
-*
-* `workflow` alone would nearly do it — its subpaths are what user code imports —
-* but the `@workflow/*` internals are what the transform's own emitted imports
-* reach for, and inlining those is most of the 12 MB.
-*/
-const WDK_EXTERNAL = [
-	"workflow",
-	"@workflow/core",
-	"@workflow/errors",
-	"@workflow/utils",
-	"@workflow/world"
-];
-/** Scratch directory for the builder's file output, under the CLI's own dot-dir. */
-const SCRATCH_REL = path.join(".aai", "workflow-build");
-/**
-* What makes a CJS dependency survive into the ESM step bundle.
-*
-* esbuild cannot statically rewrite `require("node:assert")` inside a bundled
-* CommonJS module, so it emits a `__require` shim — and that shim's fallback
-* THROWS: `Dynamic require of "node:assert" is not supported`. A step bundles
-* everything it imports and npm is full of CJS, so any step reaching a package
-* with a CJS dependency anywhere in its graph failed AT MODULE LOAD, before a
-* single line of the step ran.
-*
-* That is not a hypothetical, and the way it presents is the argument for
-* fixing it here. `research-workflow` imports `webSearch` from
-* `@alexkroman1/aai/tools`, which reaches `host/ssrf.ts`, which imports
-* **undici** — 118 dynamic requires, all of them `node:` builtins. `aai dev`
-* then never listened at all: the message named a Node builtin the author
-* never mentions, nothing named the package or the import that pulled it, and
-* because the step bundle is loaded before the server binds there was no
-* server to ask. It also does not reproduce in-tree, where `@dev/source`
-* resolves the SDK to TypeScript — only against the published `dist` — so
-* every gate short of the e2e suite was green.
-*
-* The shim itself is the fix's whole mechanism: esbuild writes
-* `typeof require !== "undefined" ? require : <thrower>`, so a real `require`
-* in scope is USED. This defines one from `import.meta.url` and is prepended,
-* which puts it ahead of the `var __require = …` initializer that reads it.
-* The flow bundle deliberately gets none — it is compiled in a `node:vm`
-* Script, where `import.meta` does not exist.
-*/
-const STEP_REQUIRE_SHIM = [
-	"import { createRequire as __aaiCreateRequire } from \"node:module\";",
-	"const require = __aaiCreateRequire(import.meta.url);",
-	""
-].join("\n");
-/**
-* The builder, with the config gotchas above applied once.
-*
-* `BaseBuilder` is abstract over `build()`, so a subclass is the supported way to
-* choose which bundles to emit and how — the WDK's own framework integrations do
-* the same.
-*/
-var AaiWorkflowBuilder = class extends BaseBuilder {
-	/**
-	* Where `build()` leaves its result.
-	*
-	* `BaseBuilder.build()` is typed `Promise<void>`, so a subclass cannot return
-	* the artifacts from it — and parameter properties are unavailable under this
-	* repo's `erasableSyntaxOnly`, so the fields are declared the long way too.
-	*/
-	output;
-	/**
-	* The two bundles `build()` reads back.
-	*
-	* Held as fields because `super()` is also told where to write them: derived
-	* a second time inside `build()`, the two spellings of each path were free to
-	* disagree, and a `build()` reading a file the builder never wrote is a
-	* "produced nothing" failure that names neither path.
-	*/
-	flowFile;
-	stepFile;
-	constructor(cwd, outDir) {
-		const flowFile = path.join(outDir, "flow.mjs");
-		const stepFile = path.join(outDir, "step.mjs");
-		super({
-			buildTarget: "standalone",
-			dirs: [`./${WORKFLOWS_DIR}`],
-			workingDir: cwd,
-			projectRoot: cwd,
-			moduleSpecifierRoot: cwd,
-			externalPackages: [...WDK_EXTERNAL],
-			stepsBundlePath: stepFile,
-			workflowsBundlePath: flowFile,
-			webhookBundlePath: path.join(outDir, "webhook.mjs"),
-			suppressCreateWorkflowsBundleLogs: true,
-			suppressCreateWebhookBundleLogs: true,
-			suppressCreateManifestLogs: true
-		});
-		this.flowFile = flowFile;
-		this.stepFile = stepFile;
-	}
-	async build() {
-		const inputFiles = await this.getInputFiles();
-		const { manifest } = await this.createWorkflowsBundle({
-			inputFiles,
-			format: "esm",
-			outfile: this.flowFile,
-			bundleFinalOutput: false
-		});
-		await this.createStepsBundle({
-			inputFiles,
-			format: "esm",
-			outfile: this.stepFile
-		});
-		const [workflowCode, stepCode] = await Promise.all([fs.readFile(this.flowFile, "utf-8"), fs.readFile(this.stepFile, "utf-8")]);
-		assertNoVmRequires(workflowCode);
-		this.output = {
-			workflowCode,
-			stepCode: STEP_REQUIRE_SHIM + stepCode,
-			manifest,
-			inputFiles,
-			warnings: replayWarnings(workflowCode)
-		};
-	}
-};
-/**
-* Attach the compiler's `workflowId`/`stepId` to the agent bundle's copy of
-* each directive body — the third transform, see the module doc.
-*
-* `enforce: "pre"` so it sees the file before Vite's own TypeScript pass: the
-* swc transform reads types itself (it is given the filename to infer syntax),
-* and its output is plain JS that the later pass leaves alone.
-*
-* @internal
-*/
-function workflowClientPlugin(cwd, inputFiles) {
-	const scanned = new Set(inputFiles.map((file) => path.resolve(cwd, file)));
-	return {
-		name: "aai:workflow-client",
-		enforce: "pre",
-		async transform(code, id) {
-			const file = path.resolve(id.split("?")[0] ?? id);
-			if (!scanned.has(file)) return;
-			if (!shouldTransformFile(file, detectWorkflowPatterns(code))) return;
-			const { code: transformed } = await applySwcTransform(path.relative(cwd, file), code, "client", file, cwd, cwd);
-			return {
-				code: transformed,
-				map: null
-			};
-		}
-	};
-}
-/**
-* Build a project's workflows, or resolve `undefined` when it declares none.
-*
-* `undefined` rather than empty strings, because "this project has no workflows"
-* is the common case — every voice agent that never reaches for one — and the
-* guest must be able to tell it apart from "the build produced nothing", which
-* would be a bug.
-*
-* @internal
-*/
-async function buildWorkflows(cwd) {
-	if (!await hasWorkflowsDir(cwd)) return;
-	const outDir = path.join(cwd, SCRATCH_REL);
-	await fs.mkdir(outDir, { recursive: true });
-	try {
-		const builder = new AaiWorkflowBuilder(cwd, outDir);
-		await builder.build();
-		const built = builder.output;
-		if (!built) return;
-		return built.workflowCode.trim() === "" ? void 0 : built;
-	} finally {
-		await fs.rm(outDir, {
-			recursive: true,
-			force: true
-		}).catch(() => void 0);
-	}
-}
-/** Does this project have a `workflows/` directory with anything in it? */
-async function hasWorkflowsDir(cwd) {
-	try {
-		return (await fs.readdir(path.join(cwd, WORKFLOWS_DIR))).some((name) => /\.(ts|tsx|js|jsx|mjs)$/.test(name));
-	} catch {
-		return false;
-	}
-}
-//#endregion
-//#region worker-bundler.ts
-/**
-* Generated wrapper entry, written under `.aai/` for the duration of the
-* build (the CLI's own scratch dir — dot-paths are ignored by the dev
-* watcher, and the studio's workspace materialization never writes there).
-*/
-const WRAPPER_ENTRY_REL = path.join(".aai", "worker-entry.ts");
-/** Extensions a tool module may be authored in (mirrors the SDK's registry). */
-const TOOL_MODULE_EXT_RE = /\.(?:m?ts|tsx)$/;
-/** A co-located spec is not a tool. */
-const TOOL_SPEC_RE = /\.(?:test|spec)\.[^.]+$/;
-/**
-* The project's `tools/` directory, as file names relative to it.
-*
-* **This is the whole of "discovery", and it happens HERE because the guest has
-* no filesystem.** A sandbox is handed one ESM string, so the only place a
-* directory can be turned into modules is where the bundle is assembled — the
-* same lowering eve does (`readdir` → static import list, which the bundler then
-* follows). The names are validated by `toolRegistry` at bundle-evaluation time
-* rather than here, so one implementation owns the rules.
-*
-* Sorted, so the emitted entry is byte-stable for a given directory: an entry
-* that reordered per readdir would change the bundle hash for no reason.
-*/
-async function discoverToolFiles(cwd) {
-	const root = path.join(cwd, "tools");
-	let entries;
-	try {
-		entries = await fs.readdir(root, {
-			withFileTypes: true,
-			recursive: true
-		});
-	} catch (err) {
-		if (errorCode(err) === "ENOENT") return [];
-		throw err;
-	}
-	return entries.filter((e) => e.isFile() && TOOL_MODULE_EXT_RE.test(e.name) && !TOOL_SPEC_RE.test(e.name)).map((e) => path.relative(root, path.join(e.parentPath, e.name)).split(path.sep).join("/")).sort();
-}
-/** The prose slot: one file, beside `agent.ts`, named by convention. */
-const SYSTEM_PROMPT_FILE = "system-prompt.md";
-/**
-* Whether the project keeps its system prompt in a file.
-*
-* The other half of "a file beside `agent.ts` can BE the thing", and it happens
-* here for the same reason `discoverToolFiles` does — the guest has no
-* filesystem, so the read belongs where the bundle is assembled. What the file
-* MEANS is `withSystemPrompt`'s to decide (the author may have imported and
-* composed it, in which case discovery must not apply it twice); this only
-* answers whether there is one.
-*/
-async function hasSystemPromptFile(cwd) {
-	const nested = path.join(cwd, "system-prompt");
-	if ((await fs.stat(nested).catch(() => void 0))?.isDirectory() === true) throw new Error(`${nested} is a directory. A system prompt is ONE file — rename it to ${SYSTEM_PROMPT_FILE}, or import the pieces yourself and compose them into \`systemPrompt\`. There is deliberately no concatenation order for a directory.`);
-	try {
-		return (await fs.stat(path.join(cwd, SYSTEM_PROMPT_FILE))).isFile();
-	} catch (err) {
-		if (errorCode(err) === "ENOENT") return false;
-		throw err;
-	}
-}
-function wrapperEntrySource(runtime, workflows, toolFiles, systemPromptFile) {
-	const toolImports = toolFiles.map((file, i) => `import * as __aaiTool${i} from "../tools/${file}";`).join("\n");
-	const toolEntries = toolFiles.map((file, i) => `  ${JSON.stringify(`tools/${file}`)}: __aaiTool${i},`).join("\n");
-	return `import def from "../agent.ts";
-import { agentToolsToSchemas, toAgentConfig, toolRegistry, withSystemPrompt, withTools } from "@alexkroman1/aai/manifest";
-${runtime ? `import { createRuntime } from "@alexkroman1/aai-runtime";` : ""}
-${systemPromptFile ? `import __aaiSystemPrompt from "../${SYSTEM_PROMPT_FILE}?raw";` : ""}
-${toolImports}
-// A tool's name is its file name. The map is built here rather than written in
-// agent.ts, so a file that exists is a tool the model can call — there is no
-// registration step to forget.
-//
-// \`system-prompt.md\` arrives the same way, and the \`?raw\` lives HERE rather
-// than in the author's own \`agent.ts\`: it is a Vite convention, and the whole
-// point of generating this entry is that a bundler feature never has to appear
-// in user-authored space.
-const __aaiAgent = ${systemPromptFile ? "withSystemPrompt(" : ""}withTools(
-  def,
-  toolRegistry({
-${toolEntries}
-  }),
-)${systemPromptFile ? ", __aaiSystemPrompt)" : ""};
-export default __aaiAgent;
-export const __aaiConfig = {
-  ...toAgentConfig(__aaiAgent),
-  toolSchemas: agentToolsToSchemas(__aaiAgent.tools ?? {}),
-};
-${runtime ? `export const __aaiCreateRuntime = (opts: Record<string, unknown>) =>
-  createRuntime({ ...opts, agent: __aaiAgent });
-` : ""}${workflows ? `// The compiled workflow surface, carried as DATA. \`__aaiWorkflowCode\` goes to
-// \`workflowEntrypoint(code)\` and \`__aaiStepCode\` is evaluated by the guest so its
-// \`registerStepFunction\` calls run. Strings rather than modules because the guest
-// receives exactly one ESM string and never sees this project's filesystem.
-export const __aaiWorkflowCode = ${JSON.stringify(workflows.workflowCode)};
-export const __aaiStepCode = ${JSON.stringify(workflows.stepCode)};
-` : ""}`;
-}
-/**
-* Bundle agent.ts into a single ESM string for the sandbox worker.
-*
-* Zod is bundled in — zod 4's `Function()` usage is wrapped in try/catch
-* and gracefully degrades in restricted environments like Deno.
-*
-* @internal — build hook for aai-server/the studio; not a supported public
-* API and not covered by semver.
-*/
-async function buildWorker(cwd, opts = {}) {
-	const wrapperPath = path.join(cwd, WRAPPER_ENTRY_REL);
-	const [, toolFiles, systemPromptFile] = await Promise.all([
-		fs.mkdir(path.dirname(wrapperPath), { recursive: true }),
-		discoverToolFiles(cwd),
-		hasSystemPromptFile(cwd)
-	]);
-	await fs.writeFile(wrapperPath, wrapperEntrySource(opts.runtime !== false, opts.workflows, toolFiles, systemPromptFile), "utf-8");
-	const plugins = [...opts.plugins ?? [], ...opts.workflows ? [workflowClientPlugin(cwd, opts.workflows.inputFiles)] : []];
-	let result;
-	try {
-		result = await withPreservedNodeEnv(() => build({
-			root: cwd,
-			logLevel: "silent",
-			...opts.configFile === false && { configFile: false },
-			...plugins.length > 0 && { plugins },
-			ssr: { noExternal: true },
-			build: {
-				ssr: true,
-				lib: {
-					entry: wrapperPath,
-					formats: ["es"],
-					fileName: "worker"
-				},
-				target: "node20",
-				minify: opts.minify ? "oxc" : false,
-				write: false,
-				rollupOptions: { output: {
-					entryFileNames: "[name].js",
-					codeSplitting: false
-				} }
-			}
-		}));
-	} finally {
-		await fs.rm(wrapperPath, { force: true }).catch(() => void 0);
-	}
-	const output = Array.isArray(result) ? result[0] : result;
-	if (!output) throw new Error("Vite produced no output for agent.ts");
-	const chunk = output.output.find((o) => o.type === "chunk" && o.isEntry);
-	if (!chunk) throw new Error("Vite produced no entry chunk for agent.ts");
-	return chunk.code;
-}
-//#endregion
-export { buildWorkflows as n, buildWorker as t };