@tailor-platform/sdk 1.66.1 → 2.0.0-next.1

package/docs/cli/function.md

@@ -209,7 +209,7 @@ $ tailor-sdk function logs <execution-id> --json
 
 When viewing a specific execution that failed, the command displays error details with the stack trace mapped back to your original source files (clickable file links and code snippets, matching `function test-run` output).
 
-Stack traces stay accurate even after later redeploys, because the trace is resolved against the exact build that produced the execution. If that build is no longer available, the command falls back to a plain-text error display.
+Stack traces are mapped only when the execution includes a content hash for the exact build that ran. If the content hash is missing or the build is no longer available, the command falls back to a plain-text error display.
 
 <!-- politty:command:function logs:notes:end -->
 

package/docs/cli/user.md

@@ -201,9 +201,9 @@ tailor-sdk user switch <user>
 
 **Arguments**
 
-| Argument | Description | Required |
-| -------- | ----------- | -------- |
-| `user`   | User email  | Yes      |
+| Argument | Description                                  | Required |
+| -------- | -------------------------------------------- | -------- |
+| `user`   | User email address or machine user client ID | Yes      |
 
 <!-- politty:command:user switch:arguments:end -->
 

package/docs/cli/workspace.md

@@ -79,7 +79,7 @@ tailor-sdk workspace create [options]
 | `--organization-id <ORGANIZATION_ID>` | `-o`  | Organization ID to workspace associate with                                                                 | No       | -         | `TAILOR_PLATFORM_ORGANIZATION_ID` |
 | `--folder-id <FOLDER_ID>`             | `-f`  | Folder ID to workspace associate with                                                                       | No       | -         | `TAILOR_PLATFORM_FOLDER_ID`       |
 | `--profile-name <PROFILE_NAME>`       | `-p`  | Profile name to create                                                                                      | No       | -         | -                                 |
-| `--profile-user <PROFILE_USER>`       | -     | User email for the profile (defaults to current user)                                                       | No       | -         | -                                 |
+| `--profile-user <PROFILE_USER>`       | -     | User email address or machine user client ID for the profile (defaults to current user)                     | No       | -         | -                                 |
 | `--permission <PERMISSION>`           | -     | Profile permission (requires --profile-name). 'read' blocks all write commands while the profile is active. | No       | `"write"` | -                                 |
 
 <!-- politty:command:workspace create:options:end -->
@@ -243,7 +243,7 @@ tailor-sdk profile create [options] <name>
 
 | Option                                            | Alias | Description                                                                                                                            | Required | Default   |
 | ------------------------------------------------- | ----- | -------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------- |
-| `--user <USER>`                                   | `-u`  | User email                                                                                                                             | Yes      | -         |
+| `--user <USER>`                                   | `-u`  | User email address or machine user client ID                                                                                           | Yes      | -         |
 | `--workspace-id <WORKSPACE_ID>`                   | `-w`  | Workspace ID                                                                                                                           | Yes      | -         |
 | `--permission <PERMISSION>`                       | -     | Profile permission. 'read' blocks all write commands while the profile is active.                                                      | No       | `"write"` |
 | `--machine-user <MACHINE_USER>`                   | `-m`  | Default machine user name for application-data commands (query, workflow start, function test-run, machineuser token).                 | No       | -         |
@@ -324,7 +324,7 @@ tailor-sdk profile update [options] <name>
 
 | Option                                            | Alias | Description                                                                                                                                                           | Required | Default |
 | ------------------------------------------------- | ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
-| `--user <USER>`                                   | `-u`  | New user email                                                                                                                                                        | No       | -       |
+| `--user <USER>`                                   | `-u`  | New user email address or machine user client ID                                                                                                                      | No       | -       |
 | `--workspace-id <WORKSPACE_ID>`                   | `-w`  | New workspace ID                                                                                                                                                      | No       | -       |
 | `--permission <PERMISSION>`                       | -     | Profile permission. 'read' blocks all write commands; 'write' lifts the restriction.                                                                                  | No       | -       |
 | `--machine-user <MACHINE_USER>`                   | `-m`  | Default machine user name for application-data commands (query, workflow start, function test-run, machineuser token). Pass an empty string to clear.                 | No       | -       |

package/docs/configuration.md

@@ -294,5 +294,3 @@ export const plugins = definePlugins(
   enumConstantsPlugin({ distPath: "./generated/enums.ts" }),
 );
 ```
-
-See [Generators](./generator/index.md) for legacy `defineGenerators()` documentation.

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.

package/docs/services/auth.md

@@ -310,8 +310,6 @@ export default createResolver({
 
 Type narrowing is provided by the generated `tailor.d.ts` (the `MachineUserNameRegistry` interface). Run `tailor-sdk generate` (or `apply`) after defining new machine users to refresh it.
 
-> **Deprecated:** The `auth.invoker("<name>")` helper is still available for backward compatibility. Prefer the string form — it does not require importing `auth` from `tailor.config.ts` into runtime files, avoiding bundling config-layer (Node-only) dependencies.
-
 ## OAuth 2.0 Clients
 
 Configure OAuth 2.0 clients for third-party applications:

package/docs/services/executor.md

@@ -347,8 +347,6 @@ export default createExecutor({
 });
 ```
 
-> **Deprecated:** `auth.invoker("batch-processor")` still works, but is deprecated. Prefer the string form to avoid importing config-layer modules into runtime files.
-
 ## Event Payloads
 
 Each trigger type provides specific context data in the callback functions.

package/docs/services/resolver.md

@@ -240,7 +240,7 @@ Define actual resolver logic in the `body` function. Function arguments include:
 
 ### Using Kysely for Database Access
 
-If you're generating Kysely types with a generator, you can use `getDB` to execute typed queries:
+If you're generating Kysely types with `kyselyTypePlugin`, you can use `getDB` to execute typed queries:
 
 ```typescript
 import { getDB } from "../generated/tailordb";
@@ -306,7 +306,7 @@ createResolver({
 
 - When `publishEvents: true`, resolver execution events are published
 - When not specified, it is **automatically set to `true`** if an executor uses this resolver with `resolverExecutedTrigger`
-- When explicitly set to `false` while an executor uses this resolver, an error is thrown during `tailor apply`
+- When explicitly set to `false` while an executor uses this resolver, an error is thrown during `tailor-sdk deploy`
 
 **Use cases:**
 
@@ -371,6 +371,4 @@ export default createResolver({
 
 The machine user name is looked up in the auth service configured on your app (`machineUsers` in `defineAuth`). The namespace is resolved automatically — no need to import `auth` from `tailor.config.ts` in resolver files.
 
-> **Deprecated:** `auth.invoker("batch-processor")` still works, but is deprecated. Importing `auth` into runtime files pulls config-layer (Node-only) dependencies into the bundle.
-
 **Note:** `authInvoker` controls the permissions for database operations and other platform actions. The `user` object passed to `body` still reflects the original caller, while `invoker` reflects the principal actually running the body.

package/docs/services/tailordb.md

@@ -461,7 +461,7 @@ db.type("User", {
 
 - When `publishEvents: true`, record creation/update/deletion events are published
 - When not specified, it is **automatically set to `true`** if an executor uses this type with `recordCreatedTrigger`, `recordUpdatedTrigger`, or `recordDeletedTrigger`
-- When explicitly set to `false` while an executor uses this type, an error is thrown during `tailor apply`
+- When explicitly set to `false` while an executor uses this type, an error is thrown during `tailor-sdk deploy`
 
 **Use cases:**
 

package/docs/services/workflow.md

@@ -105,11 +105,11 @@ import { sendNotification } from "./jobs/send-notification";
 
 export const mainJob = createWorkflowJob({
   name: "main-job",
-  body: async (input: { customerId: string }) => {
-    const customer = await fetchCustomer.trigger({
+  body: (input: { customerId: string }) => {
+    const customer = fetchCustomer.trigger({
       customerId: input.customerId,
     });
-    const notification = await sendNotification.trigger({
+    const notification = sendNotification.trigger({
       message: "Order processed",
       recipient: customer.email,
     });
@@ -130,31 +130,31 @@ Using `.trigger()` inside a loop works correctly, as long as the loop is determi
 // ✅ OK: deterministic loop — same calls in the same order on every execution
 const regions = ["us", "eu", "ap"];
 for (const region of regions) {
-  const result = await fetchData.trigger({ region });
+  const result = fetchData.trigger({ region });
   results.push(result);
 }
 ```
 
 ```typescript
 // ❌ Bad: non-deterministic — argument changes between executions
-await processJob.trigger({ timestamp: Date.now() });
+processJob.trigger({ timestamp: Date.now() });
 
 // ✅ OK: call Date.now() in separated job
-const timestamp = await timestampJob.trigger();
-await processJob.trigger({ timestamp });
+const timestamp = timestampJob.trigger();
+processJob.trigger({ timestamp });
 ```
 
 ```typescript
 // ❌ Bad: non-deterministic — external data may change between executions
 const items = await fetch("https://api.example.com/items").then((r) => r.json());
 for (const item of items) {
-  await processItem.trigger({ id: item.id });
+  processItem.trigger({ id: item.id });
 }
 
 // ✅ OK: call fetch("https://api.example.com/items").then((r) => r.json()); in separated job
-const items = await fetchItemsJob.trigger();
+const items = fetchItemsJob.trigger();
 for (const item of items) {
-  await processItem.trigger({ id: item.id });
+  processItem.trigger({ id: item.id });
 }
 ```
 
@@ -178,15 +178,15 @@ import { sendNotification } from "./jobs/send-notification";
 // Jobs must be named exports
 export const processOrder = createWorkflowJob({
   name: "process-order",
-  body: async (input: { customerId: string }, { env, invoker }) => {
+  body: (input: { customerId: string }, { env, invoker }) => {
     // `env` contains values from `tailor.config.ts` -> `env`.
     // `invoker` is the principal running this job, overridden by `authInvoker`
     // when set; `null` for anonymous calls.
     // Trigger other jobs by calling .trigger() on the job object.
-    const customer = await fetchCustomer.trigger({
+    const customer = fetchCustomer.trigger({
       customerId: input.customerId,
     });
-    await sendNotification.trigger({
+    sendNotification.trigger({
       message: "Order processed",
       recipient: customer.email,
     });
@@ -383,8 +383,6 @@ export default createResolver({
 });
 ```
 
-> **Deprecated:** `auth.invoker("manager-machine-user")` still works but is deprecated. Using the string form avoids importing `auth` into runtime code.
-
 See the full working example in the repository: [example/resolvers/triggerWorkflow.ts](https://github.com/tailor-platform/sdk/blob/main/example/resolvers/triggerWorkflow.ts).
 
 ## File Organization

package/docs/testing.md

@@ -12,7 +12,9 @@ Lean on unit tests for the day-to-day feedback loop — they run fast and exerci
 Unit-test entrypoints exposed by the SDK:
 
 - `resolver.body({ input, user, env })` — invoke a resolver
-- `workflowJob.body(input, { env })` / `workflowJob.trigger(input)` — invoke or chain a workflow job
+- `workflowJob.body(input, { env })` — invoke a workflow job body directly
+- `workflowJob.trigger(input)` — chain a workflow job through the workflow runtime
+- `runWorkflowLocally(workflow, args)` — run a workflow chain locally with real job bodies
 - `executor.operation.body(args)` — invoke a function-kind executor
 
 Helpers under `@tailor-platform/sdk/test`:
@@ -23,6 +25,7 @@ Platform API mocks under `@tailor-platform/sdk/vitest` (for use with the [`tailo
 
 - `mockTailordb` — TailorDB query stubs and call recording
 - `mockWorkflow` — `tailor.workflow` job / wait / resolve mocks
+- `runWorkflowLocally` — local full-chain workflow runner
 - `mockSecretmanager`, `mockAuthconnection`, `mockIdp`, `mockFile`, `mockIconv` — corresponding platform API mocks
 
 For tighter alignment with the production runtime — Node.js module blocking, Web-only globals, and platform API mocks — pair the resolver helpers with the [`tailor-runtime` Vitest environment](#runtime-environment-emulation-beta) below.
@@ -126,7 +129,7 @@ test("content-based mock", async () => {
 
 ### Workflow Mock
 
-`.trigger()` runs the real job bodies locally out of the box (see [Running a full workflow locally](#running-a-full-workflow-locally)). Acquire `mockWorkflow()` when you want to override responses with `setJobHandler` / `enqueueResult` or assert on `triggeredJobs`:
+Workflow job `.trigger()` calls use the platform workflow runtime. Acquire `mockWorkflow()` when you want to provide trigger responses with `setJobHandler` / `enqueueResult` or assert on `triggeredJobs`. If no response is configured, the mock throws so missing job mocks fail loudly:
 
 ```typescript
 import { mockWorkflow } from "@tailor-platform/sdk/vitest";
@@ -645,16 +648,16 @@ import { fulfillOrder, processPayment, sendConfirmation, validateOrder } from ".
 
 describe("fulfillOrder", () => {
   test("chains validate → pay → confirm", async () => {
-    using _validateSpy = vi.spyOn(validateOrder, "trigger").mockResolvedValue({
+    using _validateSpy = vi.spyOn(validateOrder, "trigger").mockReturnValue({
       valid: true,
       orderId: "order-1",
     });
-    using _paymentSpy = vi.spyOn(processPayment, "trigger").mockResolvedValue({
+    using _paymentSpy = vi.spyOn(processPayment, "trigger").mockReturnValue({
       transactionId: "txn-order-1",
       amount: 100,
       status: "completed",
     });
-    using _confirmSpy = vi.spyOn(sendConfirmation, "trigger").mockResolvedValue({
+    using _confirmSpy = vi.spyOn(sendConfirmation, "trigger").mockReturnValue({
       orderId: "order-1",
       transactionId: "txn-order-1",
       confirmed: true,
@@ -708,22 +711,27 @@ describe("processWithApproval", () => {
 
 #### Running a full workflow locally
 
-To exercise the full chain with real job bodies, just call `workflow.mainJob.trigger()` — no `mockWorkflow()` needed. Dependent jobs run their real `.body()` functions, and trigger args/results cross the same JSON boundary as the platform, so a non-serializable payload fails the test exactly as it would in production:
+To exercise the full chain with real job bodies, call `runWorkflowLocally(workflow, args)`. Dependent jobs run their real `.body()` functions, and trigger args/results cross the same JSON boundary as the platform, so a non-serializable payload fails the test exactly as it would in production:
 
 ```typescript
+import { runWorkflowLocally } from "@tailor-platform/sdk/vitest";
 import { describe, expect, test } from "vitest";
 import workflow from "./order-fulfillment";
 
 describe("order-fulfillment workflow", () => {
-  test("mainJob.trigger() executes all jobs", async () => {
-    const result = await workflow.mainJob.trigger({ orderId: "order-3", amount: 300 });
+  test("runWorkflowLocally() executes all jobs", async () => {
+    const result = await runWorkflowLocally(workflow, { orderId: "order-3", amount: 300 });
 
     expect(result).toMatchObject({ confirmed: true, paymentStatus: "completed" });
   });
 });
 ```
 
-Acquire `mockWorkflow()` only when you need to override a dependent job with `wf.setJobHandler(...)` / `wf.enqueueResult(...)` (the rest still run their real bodies), control the env via `wf.setEnv(...)`, or assert on `wf.triggeredJobs`.
+Pass `{ env }` as the third argument when job bodies need configuration values during the local run.
+
+Like the platform runtime, the local runner re-runs the orchestrator body once per `.trigger()` call (N triggers means N+1 passes), so any side effects outside the trigger results fire on every pass. Keep the body deterministic and move repeatable side effects into the triggered jobs.
+
+This helper is still a local runner. Use E2E tests when you need to verify deployed workflow scheduling, suspension, or replay behavior.
 
 **Use when:** you want to verify orchestration end to end without the cost of a real deployment.
 
@@ -823,14 +831,13 @@ Use `startWorkflow` from the CLI helpers. It starts the workflow on the deployed
 import { randomUUID } from "node:crypto";
 import { startWorkflow } from "@tailor-platform/sdk/cli";
 import { describe, expect, test } from "vitest";
-import config from "../tailor.config";
 import userProfileSync from "../src/workflow/sync-profile";
 
 describe("user-profile-sync workflow", () => {
   test("executes end to end", { timeout: 180_000 }, async () => {
     const { executionId, wait } = await startWorkflow({
       workflow: userProfileSync,
-      authInvoker: config.auth.invoker("admin"),
+      authInvoker: "admin",
       arg: {
         name: "workflow-test",
         email: `wf-${randomUUID()}@example.com`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "1.66.1",
+  "version": "2.0.0-next.1",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -9,8 +9,7 @@
     "directory": "packages/sdk"
   },
   "bin": {
-    "tailor-sdk": "./dist/cli/index.mjs",
-    "tailor-sdk-skills": "./dist/cli/skills.mjs"
+    "tailor-sdk": "./dist/cli/index.mjs"
   },
   "files": [
     "CHANGELOG.md",
@@ -139,8 +138,8 @@
     "@badgateway/oauth2-client": "3.3.1",
     "@bufbuild/protobuf": "2.12.0",
     "@bufbuild/protovalidate": "1.2.0",
-    "@connectrpc/connect": "2.1.1",
-    "@connectrpc/connect-node": "2.1.1",
+    "@connectrpc/connect": "2.1.2",
+    "@connectrpc/connect-node": "2.1.2",
     "@inquirer/core": "11.2.1",
     "@inquirer/prompts": "8.5.2",
     "@jridgewell/trace-mapping": "0.3.31",
@@ -160,10 +159,10 @@
     "chokidar": "5.0.0",
     "confbox": "0.2.4",
     "date-fns": "4.4.0",
-    "es-toolkit": "1.47.0",
+    "es-toolkit": "1.47.1",
     "find-up-simple": "1.0.1",
     "globals": "17.6.0",
-    "graphql": "16.14.1",
+    "graphql": "16.14.2",
     "inflection": "3.0.2",
     "kysely": "0.29.2",
     "madge": "8.0.0",
@@ -175,7 +174,7 @@
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.3.1",
     "politty": "0.6.0",
-    "rolldown": "1.1.0",
+    "rolldown": "1.1.1",
     "semver": "7.8.4",
     "sql-highlight": "6.1.0",
     "std-env": "4.1.0",
@@ -230,6 +229,8 @@
     "build": "tsdown && politty generate-worker --bin dist/cli/index.mjs --program tailor-sdk --shell zsh --verify",
     "lint": "oxlint --type-aware .",
     "check:public-api-jsdoc": "tsx scripts/check-public-api-jsdoc.ts",
+    "check:zod-isolation": "tsx scripts/check-zod-isolation.ts",
+    "check:import-cycles": "tsx scripts/check-import-cycles.ts",
     "lint:fix": "oxlint --type-aware . --fix",
     "typecheck": "tsc --noEmit",
     "typecheck:go": "tsgo",

package/dist/actor-D_2aJjYO.d.mts

@@ -1,24 +0,0 @@
-import { A as InferredAttributeList, j as InferredAttributeMap } from "./tailordb-C-ar4XCX.mjs";
-
-//#region src/types/actor.d.ts
-/** User type enum values from the Tailor Platform server. */
-type TailorActorType = "USER_TYPE_USER" | "USER_TYPE_MACHINE_USER" | "USER_TYPE_UNSPECIFIED";
-/** Represents an actor in event triggers. */
-type TailorActor = {
-  /** The ID of the workspace the user belongs to. */workspaceId: string; /** The ID of the user. */
-  userId: string;
-  /**
-   * A map of the user's attributes.
-   * Maps from server's `attributeMap` field.
-   */
-  attributes: InferredAttributeMap | null;
-  /**
-   * A list of the user's attributes.
-   * Maps from server's `attributes` field.
-   */
-  attributeList: InferredAttributeList; /** The type of the user. */
-  userType: TailorActorType;
-};
-//#endregion
-export { TailorActor as t };
-//# sourceMappingURL=actor-D_2aJjYO.d.mts.map