@tailor-platform/sdk 2.0.0-next.0 → 2.0.0-next.2

package/docs/github-actions.md

@@ -1,6 +1,6 @@
 # GitHub Actions Integration
 
-`tailor-sdk setup github` generates a GitHub Actions workflow that deploys your
+`tailor-sdk setup` generates a GitHub Actions workflow that deploys your
 Tailor Platform application automatically on push or tag.
 
 > **Beta:** This command is under active development. CLI flags, the generated
@@ -14,13 +14,16 @@ lives):
 
 ```bash
 # Branch target: deploy to stg on every push to main
-tailor-sdk setup github -n my-app-stg
+tailor-sdk setup -n my-app-stg
 
 # Tag target: deploy to production when a tag is pushed, with an approval gate
-tailor-sdk setup github -n my-app-prod \
+tailor-sdk setup -n my-app-prod \
   --tag --branch main --environment production
 ```
 
+`setup` defaults to the GitHub provider; `--provider github` (`-p github`) is
+accepted but optional, and other providers are not yet supported.
+
 After running the command, follow the **Next steps** printed to the terminal to
 set the required secrets, set the `TAILOR_PLATFORM_WORKSPACE_ID` variable, and
 commit the generated files.
@@ -33,7 +36,7 @@ before the first deploy (see [Targeting a workspace](#targeting-a-workspace)).
 ## Targets
 
 A _target_ is one workflow file that handles one deployment destination.
-Run `setup github` once per target.
+Run `setup` once per target.
 
 ### Branch target (recommended for staging)
 
@@ -41,9 +44,9 @@ The branch target fires on pull requests and pushes to the branch you specify
 (defaulting to the repository's default branch when `--branch` is omitted):
 
 ```bash
-tailor-sdk setup github -n my-app-stg
+tailor-sdk setup -n my-app-stg
 # Equivalent to:
-tailor-sdk setup github -n my-app-stg --branch main
+tailor-sdk setup -n my-app-stg --branch main
 ```
 
 What it does:
@@ -66,7 +69,7 @@ The tag target fires when a tag matching `--tag-pattern` (default `v*`) is
 pushed:
 
 ```bash
-tailor-sdk setup github -n my-app-prod \
+tailor-sdk setup -n my-app-prod \
   --tag --tag-pattern "v*" --branch main --environment production
 ```
 
@@ -136,7 +139,7 @@ environment is planned.)
 
 ## Generated files
 
-Running `setup github` creates or updates:
+Running `setup` creates or updates:
 
 ### `.github/workflows/tailor-<workspace-name>.yml`
 
@@ -148,10 +151,10 @@ edit or rename them — the SDK tracks them by id.
 
 You can add your own jobs and steps around the managed ones. To add
 project-specific setup (such as private registry authentication or a system
-dependency), add a step _before_ the managed setup steps. For post-install
-extras (such as `playwright install`), add a step _after_ them.
+dependency), add a step _before_ the managed `tailor-setup` step. For
+post-install extras (such as `playwright install`), add a step _after_ it.
 
-Note that re-running `setup github` currently regenerates the whole file: if
+Note that re-running `setup` currently regenerates the whole file: if
 the file differs from what the SDK last wrote — whether you edited a managed
 step or added your own — the command stops and reports the conflict. Pass
 `--force` to discard your edits and regenerate from the current template, then
@@ -167,7 +170,7 @@ detect hand edits.
 
 ### `tailor.config.ts` (id injection)
 
-If your config does not already have an `id` field, `setup github` injects one.
+If your config does not already have an `id` field, `setup` injects one.
 This `id` must be committed alongside the workflow file. In CI, `tailor-sdk
 deploy` refuses to inject a new id — if the id were assigned fresh on each CI
 run, every deploy would create a brand-new application and lose ownership of
@@ -238,7 +241,7 @@ you can deploy any commit regardless of branch membership.
 For a monorepo where your SDK app lives in a subdirectory, pass `--dir`:
 
 ```bash
-tailor-sdk setup github -n my-app --dir apps/backend
+tailor-sdk setup -n my-app --dir apps/backend
 ```
 
 The generated workflow adds a `paths` filter on `apps/backend/**` so the
@@ -303,10 +306,10 @@ A typical setup with staging and production:
 
 ```bash
 # Staging: main → stg (deploy on every push to main)
-tailor-sdk setup github -n my-app-stg
+tailor-sdk setup -n my-app-stg
 
 # Production: tagged commits → prod, with approval gate and branch guard
-tailor-sdk setup github -n my-app-prod \
+tailor-sdk setup -n my-app-prod \
   --tag --branch main --environment production
 ```
 
@@ -326,9 +329,19 @@ gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_SECRET --env production
 
 Commit both workflow files and `.github/tailor-sdk.lock`.
 
+## Checking for drift
+
+`tailor-sdk setup check` audits the workflows recorded in
+`.github/tailor-sdk.lock` against your current config and repository, without
+writing anything. It reports when a workflow file is missing or hand-edited, a
+newer template is available, `tailor.config.ts` is no longer under the recorded
+`--dir`, or the repository default branch no longer matches a branch target's
+trigger. It exits non-zero when it finds drift, so you can run it in CI. Each
+finding names a stable rule key for future suppression.
+
 ## Updating the generated workflow
 
-When you upgrade the SDK, re-run `setup github` with the same flags to pick up
+When you upgrade the SDK, re-run `setup` with the same flags to pick up
 template improvements. If the SDK detects that you have hand-edited a managed
 section, it stops and asks you to use `--force` to overwrite your edits, or to
 move your customizations into your own steps before regenerating.

package/docs/migration/v2.md

@@ -0,0 +1,475 @@
+# Migrating to v2
+
+<!-- Generated from the sdk-codemod registry. Run `pnpm codemod:docs:update` and edit `packages/sdk-codemod/src/registry.ts` instead of this file. -->
+
+Run the codemods, then finish anything reported as not migrated automatically:
+
+```sh
+npx @tailor-platform/sdk-codemod --from <current-version> --to <target-version>
+```
+
+## defineGenerators → definePlugins
+
+**Migration:** Partially automatic
+
+Migrate defineGenerators() tuple syntax to definePlugins() with explicit plugin imports
+
+Before:
+
+```ts
+import { defineGenerators } from "@tailor-platform/sdk";
+
+export const generators = defineGenerators(
+  ["@tailor-platform/kysely-type", { distPath: "db.ts" }],
+);
+```
+
+After:
+
+```ts
+import { definePlugins } from "@tailor-platform/sdk";
+import { kyselyTypePlugin } from "@tailor-platform/sdk/plugin/kysely-type";
+
+export const generators = definePlugins(kyselyTypePlugin({ distPath: "db.ts" }));
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+defineGenerators() is replaced by definePlugins() in v2. The codemod rewrites the
+known plugin tuples (kysely-type, enum-constants, file-utils, seed). For any
+remaining defineGenerators([...]) the codemod left in place — a plugin it does not
+know, or a non-tuple/spread form — convert it to definePlugins(pluginFn(config)),
+importing the matching plugin from its @tailor-platform/sdk/plugin/<name> subpath.
+```
+
+</details>
+
+## @tailor-platform/sdk/cli plugin imports → dedicated subpaths
+
+**Migration:** Automatic
+
+Rewrite deprecated plugin re-export imports (kyselyTypePlugin, enumConstantsPlugin, fileUtilsPlugin, seedPlugin) from `@tailor-platform/sdk/cli` to their dedicated plugin subpaths
+
+Before:
+
+```ts
+import { kyselyTypePlugin } from "@tailor-platform/sdk/cli";
+```
+
+After:
+
+```ts
+import { kyselyTypePlugin } from "@tailor-platform/sdk/plugin/kysely-type";
+```
+
+## function test-run --arg input unwrap
+
+**Migration:** Automatic
+
+Strip the deprecated {input: ...} wrapper from `tailor-sdk function test-run --arg` JSON in scripts and docs
+
+Before:
+
+```sh
+tailor-sdk function test-run resolvers/add.ts --arg '{"input":{"a":1}}'
+```
+
+After:
+
+```sh
+tailor-sdk function test-run resolvers/add.ts --arg '{"a":1}'
+```
+
+## tailor-sdk-skills → tailor-sdk skills install
+
+**Migration:** Partially automatic
+
+Replace deprecated `tailor-sdk-skills` invocations with `tailor-sdk skills install`
+
+Before:
+
+```sh
+npx tailor-sdk-skills
+```
+
+After:
+
+```sh
+tailor-sdk skills install
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+The standalone tailor-sdk-skills binary is removed in v2; call the skills install
+subcommand on the main tailor-sdk CLI instead. Replace any remaining
+tailor-sdk-skills invocations the codemod did not rewrite with
+`tailor-sdk skills install`.
+```
+
+</details>
+
+## Unify TailorUser/TailorActor/TailorActorType/TailorInvoker → TailorPrincipal
+
+**Migration:** Partially automatic
+
+Rename TailorUser/TailorActor/TailorActorType/TailorInvoker to TailorPrincipal, drop unauthenticatedTailorUser, rename resolver body `user` to `caller`, and rename TailorDB callback `user` to `invoker`
+
+Type references unify under `TailorPrincipal`:
+
+Before:
+
+```ts
+import type { TailorUser } from "@tailor-platform/sdk";
+```
+
+After:
+
+```ts
+import type { TailorPrincipal } from "@tailor-platform/sdk";
+```
+
+The resolver body `user` becomes `caller`:
+
+Before:
+
+```ts
+body: ({ input, user }) => user.id,
+```
+
+After:
+
+```ts
+body: ({ input, caller }) => caller.id,
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+Finish the cases the codemod left for manual migration:
+- Rename user -> caller in resolver bodies the codemod skipped because a `caller`
+  binding already exists or renaming would shadow/collide with another value.
+- Replace member-access on the removed unauthenticatedTailorUser (e.g.
+  unauthenticatedTailorUser.id); the codemod only replaced standalone references
+  with null and left member access to surface a type error.
+- Review helper adapters that still accept or read `context.user`; v2 resolver
+  context uses nullable `caller` and `invoker`, so project-specific helper
+  semantics for anonymous callers and command invokers must be chosen explicitly.
+- Review `caller?.` values passed to APIs that require non-null values. If the
+  resolver requires authentication, throw or otherwise narrow before the call;
+  if anonymous callers are allowed, keep the nullable flow explicit.
+Use TailorPrincipal for the unified user/actor/invoker type.
+```
+
+</details>
+
+## tailor-sdk apply → tailor-sdk deploy
+
+**Migration:** Automatic
+
+Rewrite `tailor-sdk apply` invocations in package.json scripts, shell scripts, CI configs, and docs to the canonical v2 `tailor-sdk deploy` command
+
+Before:
+
+```sh
+tailor-sdk apply --profile prod
+```
+
+After:
+
+```sh
+tailor-sdk deploy --profile prod
+```
+
+## v2 CLI rename
+
+**Migration:** Partially automatic
+
+Rewrite `tailor-sdk crash-report` to `tailor-sdk crashreport` and `--machineuser` to `--machine-user` across package.json scripts, shell scripts, CI configs, and docs
+
+Before:
+
+```sh
+tailor-sdk crash-report list
+tailor-sdk login --machineuser
+```
+
+After:
+
+```sh
+tailor-sdk crashreport list
+tailor-sdk login --machine-user
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+Apply the v2 CLI renames the codemod did not reach (only `tailor-sdk`-prefixed
+invocations are rewritten): `tailor-sdk crash-report` -> `tailor-sdk crashreport`
+and the `--machineuser` option -> `--machine-user`. Leave unrelated commands that
+happen to use `--machineuser` alone.
+```
+
+</details>
+
+## auth.invoker("name") → "name"
+
+**Migration:** Partially automatic
+
+Replace `auth.invoker("name")` calls with the bare `"name"` string and drop the `auth` import when no other reference remains. The `auth.invoker()` helper is deprecated in v2 because importing `auth` from `tailor.config.ts` into runtime files pulls Node-only modules into the bundle.
+
+Before:
+
+```ts
+createResolver({ invoker: auth.invoker("manager") });
+```
+
+After:
+
+```ts
+createResolver({ invoker: "manager" });
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+In Tailor SDK v2 the auth.invoker() helper is removed; an invoker is now the
+machine user name passed directly as a string. The codemod already rewrote the
+string-literal form auth.invoker("name") to "name". These files still contain
+auth.invoker(...) because the argument is not a plain string literal (a variable,
+template literal, function call, or property access).
+
+For each remaining auth.invoker(<expr>) call:
+1. Replace the whole call with <expr> as-is (e.g. auth.invoker(name) becomes name).
+2. Make sure <expr> evaluates to the machine user name (a string); adjust it if it
+   resolves to an object or an auth config value instead.
+3. After removing every auth.invoker usage in a file, delete the now-unused auth
+   import (keeping it pulls Node-only config modules into runtime bundles); leave
+   the import if auth is still referenced elsewhere.
+
+Do not change behavior beyond removing the auth.invoker() indirection.
+```
+
+</details>
+
+## Tailordb → tailordb (lowercase ambient namespace)
+
+**Migration:** Partially automatic
+
+Rewrite references to the removed capital-cased `Tailordb` ambient namespace (`Tailordb.QueryResult`, `Tailordb.CommandType`, `Tailordb.Client`, `typeof Tailordb.Client`) to the lowercase `tailordb.*` namespace exposed by `@tailor-platform/sdk/runtime/globals`. Because v2 no longer activates ambient declarations automatically, each file that contains `tailordb.*` references after the rewrite must also add `import "@tailor-platform/sdk/runtime/globals"`.
+
+Before:
+
+```ts
+const command: Tailordb.CommandType = "SELECT";
+```
+
+After:
+
+```ts
+import "@tailor-platform/sdk/runtime/globals";
+const command: tailordb.CommandType = "SELECT";
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+The capital-cased Tailordb ambient namespace is removed in v2; use the lowercase
+tailordb.* namespace from @tailor-platform/sdk/runtime/globals. The codemod rewrites
+the known members (QueryResult, CommandType, Client). Rewrite any other remaining
+Tailordb.* reference to its tailordb.* equivalent (and confirm the member still
+exists on the lowercase namespace).
+Also add `import "@tailor-platform/sdk/runtime/globals"` at the top of each file
+that contains any tailordb.* type reference — v2 no longer activates ambient
+declarations automatically on SDK import.
+```
+
+</details>
+
+## executeScript arg JSON.stringify → value
+
+**Migration:** Partially automatic
+
+Unwrap `JSON.stringify(...)` passed as the `executeScript` `arg` option. In v2 `arg` takes a JSON-serializable value and is serialized internally, so a pre-stringified argument double-encodes.
+
+Before:
+
+```ts
+await executeScript({ ...opts, arg: JSON.stringify({ a: 1 }) });
+```
+
+After:
+
+```ts
+await executeScript({ ...opts, arg: { a: 1 } });
+```
+
+<details>
+<summary>Prompt for an AI agent (to finish the cases the codemod could not migrate)</summary>
+
+```text
+In Tailor SDK v2 the executeScript() arg option takes a JSON-serializable value
+and is serialized internally, so a pre-stringified argument double-encodes. The
+codemod already rewrote the direct form arg: JSON.stringify(X) to arg: X. Review
+the executeScript calls in these files for cases it could not rewrite — where the
+arg value is reached indirectly, for example:
+- a variable holding a JSON.stringify(...) result (const s = JSON.stringify(x); ... arg: s)
+- JSON.stringify(x, null, 2) or another multi-argument form
+- an options object built or spread dynamically
+
+For each such call, pass the underlying value directly as arg (drop the
+JSON.stringify wrapper) so executeScript serializes it once. Leave calls that
+already pass a plain value unchanged.
+```
+
+</details>
+
+## openDownloadStream → downloadStream
+
+**Migration:** Manual
+
+The deprecated `openDownloadStream` file-streaming API is removed in v2. Use `downloadStream` for streamed file downloads. The generated file utilities now emit `downloadFileStream` (which calls `downloadStream` and returns `FileDownloadStreamResponse`) instead of the removed `openFileDownloadStream` helper.
+
+Before:
+
+```ts
+const res = await openDownloadStream(namespace, typeName, fieldName, recordId);
+```
+
+After:
+
+```ts
+const res = await downloadStream(namespace, typeName, fieldName, recordId);
+```
+
+<details>
+<summary>Prompt for an AI agent (to perform this migration)</summary>
+
+```text
+The openDownloadStream file-streaming API is removed in v2. Replace every call to
+openDownloadStream with downloadStream (same arguments). If you used the generated
+openFileDownloadStream helper, switch to downloadFileStream, which calls
+downloadStream and returns FileDownloadStreamResponse.
+```
+
+</details>
+
+## Ambient runtime globals are opt-in
+
+**Migration:** Manual
+
+Importing `@tailor-platform/sdk` no longer activates the ambient `tailor.*` / `tailordb.*` global declarations. Normal SDK development does not need them — use the SDK APIs and the typed wrappers from `@tailor-platform/sdk/runtime`. Only if you relied on the ambient globals directly, add `import "@tailor-platform/sdk/runtime/globals"`. (The capital-cased `Tailordb.*` namespace is removed separately — see the `Tailordb → tailordb` codemod.)
+
+Preferred: switch to the typed wrappers from `@tailor-platform/sdk/runtime` and drop the ambient globals:
+
+Before:
+
+```ts
+const client = new tailor.idp.Client();
+```
+
+After:
+
+```ts
+import { idp } from "@tailor-platform/sdk/runtime";
+const client = new idp.Client({ namespace: "my-namespace" });
+```
+
+Fallback: only if you must keep referencing the bare `tailor.*` names, opt into the global declarations:
+
+Before:
+
+```ts
+const client = new tailor.idp.Client();
+```
+
+After:
+
+```ts
+import "@tailor-platform/sdk/runtime/globals";
+const client = new tailor.idp.Client();
+```
+
+<details>
+<summary>Prompt for an AI agent (to perform this migration)</summary>
+
+```text
+The v2 SDK no longer enables ambient Tailor runtime globals from
+`@tailor-platform/sdk`. For each flagged file that uses `tailor.*`,
+`tailordb.*`, or Tailor runtime error globals, prefer migrating to the
+typed wrappers from `@tailor-platform/sdk/runtime` (e.g. replace
+`new tailor.idp.Client()` with `import { idp } from "@tailor-platform/sdk/runtime"`
+and `new idp.Client({ namespace })`). The wrappers are self-contained, so the
+ambient globals are no longer needed.
+
+Only when the file must keep referencing the bare `tailor.*` names directly,
+opt into the global declarations instead by adding one of these:
+- per-file: `import "@tailor-platform/sdk/runtime/globals";`
+- project-wide: `"types": ["@tailor-platform/sdk/runtime/globals"]` in
+  the relevant tsconfig compilerOptions
+
+Leave files unchanged when the matching name is local, imported from another
+module, or appears only in comments or strings.
+```
+
+</details>
+
+## Workflow .trigger() and trigger tests
+
+**Migration:** Manual
+
+Workflow job `.trigger()` now aligns with the platform runtime: it returns the job result directly instead of a Promise wrapper, and tests no longer run job bodies locally. Mock trigger responses with `mockWorkflow()` (`setJobHandler` / `enqueueResult`, assert via `triggeredJobs`), or use `runWorkflowLocally()` for a full-chain local run.
+
+Tests must mock the workflow runtime instead of running bodies locally:
+
+Before:
+
+```ts
+const result = await orderJob.trigger({ id });
+expect(result.status).toBe("done");
+```
+
+After:
+
+```ts
+using wf = mockWorkflow();
+wf.setJobHandler((jobName) => (jobName === "order-job" ? { status: "done" } : null));
+const result = await orderJob.trigger({ id });
+expect(result.status).toBe("done");
+```
+
+<details>
+<summary>Prompt for an AI agent (to perform this migration)</summary>
+
+```text
+Workflow job .trigger() now uses the platform workflow runtime instead of running
+the job body locally. In tests, acquire `using wf = mockWorkflow()` and provide
+trigger responses (setJobHandler / enqueueResult), or use runWorkflowLocally() for a
+full-chain local run; an unmocked trigger now throws. Outside tests, treat the
+trigger result as the job output directly (no Promise wrapper to unwrap).
+```
+
+</details>
+
+## Behavioral changes (no migration required)
+
+These v2 changes alter runtime or CLI behavior; no source change is needed.
+
+### CLI tokens stored in the OS keyring
+
+CLI login tokens are stored in the OS keyring by default when available, falling back to the platform config file when it is not. No source change is required; re-login if you need tokens moved into the keyring.
+
+### CLI users keyed by subject ID
+
+The CLI stores human users by their stable subject ID instead of email (email is kept for display). Legacy email-keyed entries are migrated automatically on the next login or token refresh. No source change is required.
+
+### function logs require a content hash for source mapping
+
+`tailor-sdk function logs` maps stack traces against the function bundle only when the execution recorded a `contentHash`. Executions without one now show raw stack traces instead of mapped frames. No source change is required.

package/docs/plugin/custom.md

@@ -18,7 +18,7 @@ const myPlugin: Plugin = {
 export default myPlugin; // Required: must be default export
 ```
 
-This is required so that generators can use plugin-generated TailorDB types via `getGeneratedType()`.
+This is required so that other plugins and generation-time hooks can use plugin-generated TailorDB types via `getGeneratedType()`.
 
 ## Plugin Interface
 
@@ -276,7 +276,7 @@ import type {
 
 ## getGeneratedType Helper
 
-The SDK provides an async `getGeneratedType()` helper function to retrieve plugin-generated TailorDB types. This enables generators and other tools to work with types generated by plugins.
+The SDK provides an async `getGeneratedType()` helper function to retrieve plugin-generated TailorDB types. This enables plugins and other tools to work with types generated by plugins.
 
 ```typescript
 import { join } from "node:path";

package/docs/plugin/index.md

@@ -149,7 +149,7 @@ These hooks produce TailorDB types, resolvers, and executors that become part of
 | `onResolverReady` | TailorDB types, Resolvers, Auth            | Write output files |
 | `onExecutorReady` | TailorDB types, Resolvers, Executors, Auth | Write output files |
 
-These hooks receive all finalized data and produce output files (TypeScript code, etc.). They replace the previous standalone `defineGenerators()` approach. No `importPath` required.
+These hooks receive all finalized data and produce output files (TypeScript code, etc.). No `importPath` required.
 
 A plugin can implement hooks from either or both phases.
 

package/docs/runtime.md

@@ -50,9 +50,7 @@ import type { ListUsersResponse, ClientConfig } from "@tailor-platform/sdk/runti
 
 Most users do not need to touch the globals entry — `@tailor-platform/sdk/runtime` (and its subpath modules) cover the same surface without depending on any ambient declaration.
 
-For backwards compatibility with the previous `@tailor-platform/function-types`-based setup, the SDK still activates the ambient `tailor.*` / `tailordb.*` types automatically when you import from `@tailor-platform/sdk`. **This implicit activation will be removed in v2.0**; new code should prefer the typed wrappers from `@tailor-platform/sdk/runtime`.
-
-If you want to opt into the globals explicitly (or you are migrating ahead of v2.0), add a single side-effect import anywhere in your project:
+Importing from `@tailor-platform/sdk` does not activate the ambient `tailor.*` / `tailordb.*` declarations. If you want to opt into the globals, add a single side-effect import anywhere in your project:
 
 ```ts
 import "@tailor-platform/sdk/runtime/globals";
@@ -68,6 +66,8 @@ Or register the entry in `tsconfig.json`:
 }
 ```
 
+The globals entry exposes the lowercase `tailordb.*` namespace only. If your project still references the removed capital-cased `Tailordb.*` namespace from `@tailor-platform/function-types`, migrate before upgrading in two steps: run `pnpm dlx @tailor-platform/sdk-codemod v2/tailordb-namespace` to rewrite `Tailordb.*` references to lowercase `tailordb.*`, then add the `import "@tailor-platform/sdk/runtime/globals"` opt-in above so the rewritten references resolve.
+
 ## Namespaces
 
 The runtime entry re-exports the following namespaces. Detailed signatures, parameters, and return types live in the JSDoc next to each export — hover the symbol in your IDE or browse the source.
@@ -78,7 +78,7 @@ The runtime entry re-exports the following namespaces. Detailed signatures, para
 - `idp` — IdP user management (`new Client({ namespace })`)
 - `workflow` — workflow & job control (`triggerWorkflow`, `triggerJobFunction`, `wait`, `resolve`)
 - `context` — execution context (`getInvoker`)
-- `file` — `tailordb.file` BLOB API (`upload`, `download`, `downloadAsBase64`, `delete`, `getMetadata`, `downloadStream`, `uploadStream`, `openDownloadStream` _(deprecated)_)
+- `file` — `tailordb.file` BLOB API (`upload`, `download`, `downloadAsBase64`, `delete`, `getMetadata`, `downloadStream`, `uploadStream`)
 
 ## Testing