@alexkroman1/aai-cli 9.1.0 → 10.0.0

package/dist/workflow-bundler.d.ts

@@ -1,138 +0,0 @@
-/**
- * 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.
- */
-import type { Plugin } from "vite";
-/**
- * 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.
- */
-export declare const WORKFLOWS_DIR = "workflows";
-/** What a guest needs to serve workflows for one agent. */
-export type WorkflowBundleOutput = {
-    /**
-     * The workflow-mode transform of every `"use workflow"` body, as code.
-     *
-     * Passed to `workflowEntrypoint(code)` in the guest — which is why it is a
-     * STRING rather than a file: the guest never sees this project's filesystem.
-     */
-    workflowCode: string;
-    /**
-     * The step-mode transform, as code. Evaluated in the guest so its
-     * `registerStepFunction` calls run; nothing imports anything from it.
-     */
-    stepCode: string;
-    /**
-     * The builder's manifest — `workflowId` per exported workflow, plus the step
-     * graph. The ids are what `ctx.workflows.start` needs, and the SDK reads them
-     * off each body's own `workflowId` property, so nothing consumes this at
-     * runtime; it is the builder's own output, kept for inspection and asserted
-     * by this package's spec.
-     *
-     * It is deliberately NOT emitted into the worker bundle. It was, as a
-     * double-encoded `__aaiWorkflowManifest` string literal, on the stated
-     * grounds that "the studio's workflows card renders it" — which was never
-     * true (the card calls `GET /workflows`). Nothing anywhere read the export,
-     * so it was bytes in every deploy artifact, re-fetched and hash-verified on
-     * every cold guest boot, for no reader.
-     */
-    manifest: unknown;
-    /**
-     * The absolute paths the builder scanned — the agent bundle's client
-     * transform runs over exactly these. See the module doc's third-transform
-     * section for why it is this list and not a content sniff.
-     */
-    inputFiles: readonly string[];
-    /**
-     * Replay-safety findings, as lines to print. See {@link replayWarnings} for
-     * why they are warnings rather than a failed build.
-     */
-    warnings: readonly string[];
-};
-/**
- * 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
- */
-export declare function workflowClientPlugin(cwd: string, inputFiles: readonly string[]): Plugin;
-/**
- * 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
- */
-export declare function buildWorkflows(cwd: string): Promise<WorkflowBundleOutput | undefined>;

package/dist/{_studio-CKrsixd0.mjs → _studio-B1waXMuR.mjs}

@@ -3,9 +3,9 @@ import { t as CliError } from "./_output-CKkmWs7i.mjs";
 import path from "node:path";
 import { isRecord, omitUndefined } from "@alexkroman1/aai/utils";
 import { MAX_SLUG_LENGTH, PREVIEW_SLUG_SUFFIX, VALID_SLUG_RE } from "@alexkroman1/aai/internal";
+import { isLocalOnlyFile, snapshotWorkspaceFiles } from "@alexkroman1/aai/workspace-files";
 import { FetchError, ofetch } from "ofetch";
 import { slugifyName } from "@alexkroman1/aai/slugify";
-import { isLocalOnlyFile, snapshotWorkspaceFiles } from "@alexkroman1/aai/workspace-files";
 //#region _api-client.ts
 /**
 * Shared HTTP helper for platform API calls (deploy, delete, secrets).