@alexkroman1/aai-cli 9.2.0 → 10.0.1

package/dist/_workflow-scan.d.ts

@@ -1,108 +0,0 @@
-/**
- * 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
- */
-/** One `require` the workflow VM cannot answer, and the module it was written for. */
-export type VmRequireSite = {
-    /** The module specifier — `node:child_process`. */
-    specifier: string;
-    /** The bundled file esbuild attributed it to, or `undefined` when it said none. */
-    module: string | undefined;
-};
-/**
- * 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
- */
-export declare function findVmRequires(workflowCode: string): VmRequireSite[];
-/** One replay-unsafe call the flow bundle carries, and where it came from. */
-export type ReplayUnsafeSite = {
-    /** The call, as written — `Date.now(`. */
-    call: string;
-    /** What it does on a replay, and what to do instead. */
-    fix: string;
-    /** The project file esbuild attributed it to. */
-    module: string;
-};
-/**
- * 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
- */
-export declare function findReplayUnsafeCalls(workflowCode: string): ReplayUnsafeSite[];
-/**
- * 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.
- */
-export declare function replayWarnings(workflowCode: string): string[];
-/**
- * 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.
- */
-export declare function assertNoVmRequires(workflowCode: string): void;