@tailor-platform/sdk 2.0.0-next.9 → 2.0.0

package/docs/services/resolver.md

@@ -305,12 +305,12 @@ createResolver({
 **Behavior:**
 
 - 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 deploy`
+- When not specified, `deploy` sets it from the executors taking part in the same run: `true` while one of them uses this resolver with `resolverExecutedTrigger`, and `false` once none does. Removing the last such trigger turns publishing back off on the next `deploy`
+- When explicitly set to `false` while an executor taking part in the same run uses this resolver, `deploy` fails
 
 **Use cases:**
 
-1. **Auto-detection (recommended)**: Don't set `publishEvents` - the SDK automatically enables it when needed by executors
+1. **Auto-detection (recommended)**: Don't set `publishEvents` - `deploy` enables it while an executor taking part in the same run needs it
 
    ```typescript
    // publishEvents is automatically enabled because an executor uses this resolver
@@ -339,7 +339,7 @@ createResolver({
    });
    ```
 
-3. **Explicit disable**: Disable event publishing for a resolver that doesn't need it (error if executor uses it)
+3. **Explicit disable**: Disable event publishing for a resolver that doesn't need it (error if an executor taking part in the same run uses it)
 
    ```typescript
    createResolver({
@@ -350,6 +350,62 @@ createResolver({
    });
    ```
 
+**Sharing a resolver across configs:** an executor in another config auto-enables publishing the same way, as long as both configs take part in the same `deploy` (`--config a,b`). `deploy` records that dependency, so deploying the owning config alone later asks for confirmation instead of silently turning publishing off — it fails outright in a non-interactive environment. Set `publishEvents: true` on the resolver to keep it on regardless of which configs take part.
+
+## Permissions
+
+### Access Requirement (`permission`)
+
+By default, a resolver with no in-body check is reachable by an anonymous (unauthenticated) caller. Set `permission` to reject callers that don't match a condition, evaluated before `body` runs:
+
+```typescript
+import { createResolver, t } from "@tailor-platform/sdk";
+
+export default createResolver({
+  name: "getMyOrders",
+  operation: "query",
+  permission: [{ conditions: [[{ user: "_loggedIn" }, "=", true]], permit: true }],
+  output: t.object({ count: t.int() }),
+  body: async (context) => {
+    // context.user is guaranteed to be an authenticated caller here
+    return { count: 0 };
+  },
+});
+```
+
+`permission` uses the same `conditions`/`permit` notation as TailorDB's `.permission()` — an array of policies, restricted to `user` operands (a resolver has no associated record to compare against) with equality (`=`/`!=`) comparisons:
+
+- `{ user: "_loggedIn" }` — whether the caller is authenticated
+- `{ user: "id" }` — the caller's user ID
+- `{ user: "someAttribute" }` — any string or boolean attribute enabled in `auth.userProfile.attributes` (or `auth.machineUserAttributes` for machine users); array attributes aren't supported, since conditions only compare against a single string/boolean value
+
+Multiple conditions within the same policy's `conditions` array are combined with AND. `permit` is required, with no implicit default. At least one `permit: true` policy is required: `permission` is an allow-list, denied by default and granted only by a matching `permit: true` policy. This lets you express different eligibility paths, e.g. allowing machine-user callers unconditionally while gating regular users behind a role check:
+
+```typescript
+permission: [
+  { conditions: [[{ user: "isServiceAccount" }, "=", true]], permit: true },
+  { conditions: [[{ user: "role" }, "=", "ADMIN"]], permit: true },
+],
+```
+
+A `permit: false` policy always denies matching callers, even ones another policy would otherwise allow. Combine it with a `permit: true` policy to carve out an explicit exception, e.g. granting access broadly but rejecting one banned role:
+
+```typescript
+permission: [
+  { conditions: [[{ user: "_loggedIn" }, "=", true]], permit: true },
+  { conditions: [[{ user: "role" }, "=", "BANNED"]], permit: false },
+],
+```
+
+A policy array made up of only `permit: false` policies is rejected: since none of its conditions apply to a caller presenting no user attributes at all, it wouldn't actually keep anyone out who's willing to drop their credentials, so it can't stand in for an allow-list.
+
+Besides a policy array, `permission` also accepts:
+
+- `"allowAnonymous"` — explicitly documents that anonymous callers are allowed. Behaves the same as omitting `permission`, but records the decision so it isn't mistaken for an oversight.
+- Omitted (default) — unchanged: anonymous callers can still reach the resolver.
+
+This check is based on `context.user`, the original caller, so it still applies even when `authInvoker` swaps in a machine user for database access.
+
 ## Authentication
 
 Specify an `invoker` to execute the resolver with machine user credentials. Pass the machine user name as a plain string — it is type-narrowed to the names you defined in your auth config:

package/docs/services/tailordb-migration.md

@@ -131,6 +131,16 @@ tailor tailordb migration script 0002
 
 This writes `migrations/0002/migrate.ts` and `migrations/0002/db.ts` next to the existing `diff.json`. The removed field stays readable inside `migrate.ts` because the pre-migration phase keeps it on the type until the script finishes (see [Per-migration phases](#per-migration-phases)). The next `tailor deploy` runs the script automatically — `migrate.ts` is executed whenever the file exists on disk, regardless of whether the diff itself required it.
 
+### Breaking changes without a script
+
+Breaking changes require `migrate.ts`. If it is missing at deploy time (for example, the generated script was deleted), `tailor deploy` fails before applying the migration or anything after it. When there is genuinely nothing to migrate — say, the affected type holds no data yet — record an explicit acknowledgment instead of keeping an empty script:
+
+```bash
+tailor tailordb migration script 0002 --no-script --reason "no data yet, safe to skip"
+```
+
+This stores the reason in `migrations/0002/diff.json` (commit the change). The next `tailor deploy` applies the schema change as usual, skips only the script step, and logs the recorded reason. The command refuses to record a skip while `migrate.ts` exists — delete the script first. If `migrate.ts` is added back later, the script takes precedence over the acknowledgment and runs.
+
 ## Configuration
 
 ```typescript
@@ -220,10 +230,13 @@ The `env` values are injected at bundle time (the same mechanism as resolvers/ex
 | Remove field                   | No        | Optional          | Warning tier — no script is auto-generated, but you can add one with `tailordb migration script` to preserve data before the field is dropped. The field stays readable from `migrate.ts` during Pre-migration and is dropped in Post-migration. |
 | Change optional → required     | Yes       | Yes               | Script sets defaults for null values                                                                                                                                                                                                             |
 | Change required → optional     | No        | No                | Schema change only                                                                                                                                                                                                                               |
-| Add index                      | No        | No                | Schema change only                                                                                                                                                                                                                               |
-| Remove index                   | No        | No                | Schema change only                                                                                                                                                                                                                               |
+| Add index (non-unique)         | No        | No                | Schema change only                                                                                                                                                                                                                               |
+| Add unique index               | Yes       | Yes               | Script must resolve duplicate value combinations across the index fields                                                                                                                                                                         |
+| Change unique index fields     | Yes       | Yes               | Treated like adding a new unique constraint over the new field set                                                                                                                                                                               |
+| Remove index                   | No        | No                | Schema change only (removing the unique constraint from an index is also non-breaking)                                                                                                                                                           |
 | Add unique constraint          | Yes       | Yes               | Script must resolve duplicate values                                                                                                                                                                                                             |
 | Remove unique constraint       | No        | No                | Schema change only                                                                                                                                                                                                                               |
+| Change decimal scale           | Yes       | Yes               | Auto-generated script re-saves existing rows under the new scale. Decreasing scale rounds values half-up and can lose precision. If the same change adds a unique constraint, duplicate handling runs after re-saving.                           |
 | Add enum value                 | No        | No                | Schema change only                                                                                                                                                                                                                               |
 | Remove enum value              | Yes       | Yes               | Script migrates records with removed values                                                                                                                                                                                                      |
 | Add type                       | No        | No                | Schema change only                                                                                                                                                                                                                               |
@@ -251,8 +264,8 @@ When you run `tailor deploy`, the SDK detects pending migrations (anything past
 
 For each pending migration:
 
-1. **Pre-migration**: Type changes that would be breaking are applied in a relaxed form first. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the type so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped). Non-breaking changes that are part of the same migration are also applied here.
-2. **Script execution**: If `migrate.ts` exists on disk for this migration, it is bundled and sent to the platform via the script execution API and runs as the configured machine user inside a transaction. The script is hard-required for breaking changes (`diff.requiresMigrationScript`) but is also executed when present for warning-tier diffs — see [Warnings and optional migration scripts](#warnings-and-optional-migration-scripts).
+1. **Pre-migration**: Type changes that would be breaking are applied in a relaxed form first. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the type so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped). Breaking type-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
+2. **Script execution**: If `migrate.ts` exists on disk for this migration, it is bundled and sent to the platform via the script execution API and runs as the configured machine user inside a transaction. The script is hard-required for breaking changes (`diff.requiresMigrationScript`) — deploy fails if the file is missing, unless a `--no-script` acknowledgment was recorded (see [Breaking changes without a script](#breaking-changes-without-a-script)). It is also executed when present for warning-tier diffs — see [Warnings and optional migration scripts](#warnings-and-optional-migration-scripts).
 3. **Post-migration**: Required constraints are enforced; field and type deletions are applied (the columns/tables are physically dropped here); the `sdk-migration` label is bumped to this migration's number.
 
 This split is what allows existing rows to be backfilled before the database starts rejecting nulls, and what lets `migrate.ts` traverse foreign-key fields that the same migration removes.
@@ -277,7 +290,15 @@ Namespace: tailordb
 
 The error also points you at `migration status`, `migration generate`, `migration sync`, and `migration set` — see [Remote schema drift detected](#remote-schema-drift-detected) for which one applies.
 
-To bypass both checks (not recommended outside of recovery scenarios):
+To run the same checks without deploying — plus migration file integrity (numbering, parseable contents, and a `migrate.ts` or a recorded `--no-script` acknowledgment for every migration that requires a script):
+
+```bash
+tailor tailordb migration validate
+```
+
+It reports issues per namespace, exits with a non-zero code when any check fails, and supports `--json` for machine-readable output.
+
+To bypass both checks during deploy (not recommended outside of recovery scenarios):
 
 ```bash
 tailor deploy --no-schema-check
@@ -301,6 +322,8 @@ tailor deploy --no-schema-check
 
 `tailor tailordb migration set <N>` updates the `sdk-migration` label on the deployed namespace's metadata. **It does not modify any data or schema.** It only changes which migrations the next `apply` will consider pending.
 
+The migration number is validated before anything is sent to the remote: it must be a 4-digit value (e.g. `0001`) or a bare integer (e.g. `1`) within 0–9999, and must exist in the working tree's migration history, which is itself validated (a gapped history is rejected). `0` is always accepted as the baseline (even when no migrations directory exists yet), provided the history passes validation.
+
 | Movement                         | Effect on next `apply`                                                    | Effect on data                                                |
 | -------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------- |
 | Forward (e.g., `0001` → `0003`)  | Migrations `0002` and `0003` are skipped — they will not run.             | None.                                                         |
@@ -342,7 +365,8 @@ Migration numbers are assigned sequentially, so two developers branching off the
 ### CI / CD
 
 - For non-interactive environments, pass `--yes` to `migration generate` and `--yes` to `apply`. `apply` runs migrations automatically when the `migrations/` directory is configured.
-- Run `tailor tailordb migration status` in CI to detect "developer forgot to commit a migration" situations early. The exit code is non-zero only on errors, so check the output.
+- Run `tailor tailordb migration validate` in CI to catch uncommitted migrations, broken migration files, and remote schema drift before deploying. It exits with a non-zero code when validation fails and supports `--json`.
+- `tailor tailordb migration status` shows applied and pending migrations for a human-readable comparison. Its exit code is non-zero only on errors, so check the output.
 - Avoid running migrations in parallel against the same workspace — there is no locking. Serialize deploys per environment.
 
 ### Resetting a deployed project
@@ -479,4 +503,4 @@ For genuinely different schemas across environments, prefer separate workspaces
 
 **Cause:** `diff.requiresMigrationScript` is true but `migrate.ts` is missing from the migration directory.
 
-**Resolution:** Either re-run `migration generate` (it skips already-generated diffs but will fill in a missing script), or restore the file from version control.
+**Resolution:** Restore the file from version control, or create it with `tailor tailordb migration script <N> --namespace <namespace>`. If the migration intentionally needs no data transformation, record that decision with `tailor tailordb migration script <N> --namespace <namespace> --no-script --reason "<why no data migration is needed>"` instead.

package/docs/services/tailordb.md

@@ -515,12 +515,12 @@ db.table("User", {
 **Behavior:**
 
 - 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 deploy`
+- When not specified, `deploy` sets it from the executors taking part in the same run: `true` while one of them uses this type with `recordCreatedTrigger`, `recordUpdatedTrigger`, or `recordDeletedTrigger`, and `false` once none does. Removing the last such trigger turns publishing back off on the next `deploy`
+- When explicitly set to `false` while an executor taking part in the same run uses this type, `deploy` fails
 
 **Use cases:**
 
-1. **Auto-detection (recommended)**: Don't set `publishEvents` - the SDK automatically enables it when needed by executors
+1. **Auto-detection (recommended)**: Don't set `publishEvents` - `deploy` enables it while an executor taking part in the same run needs it
 
    ```typescript
    // publishEvents is automatically enabled because an executor uses this type
@@ -545,7 +545,7 @@ db.table("User", {
    });
    ```
 
-3. **Explicit disable**: Disable event publishing for a type that doesn't need it (error if executor uses it)
+3. **Explicit disable**: Disable event publishing for a type that doesn't need it (error if an executor taking part in the same run uses it)
 
    ```typescript
    db.table("TempData", {
@@ -555,6 +555,8 @@ db.table("User", {
    });
    ```
 
+**Sharing a type across configs:** an executor in another config auto-enables publishing the same way, as long as both configs take part in the same `deploy` (`--config a,b`). `deploy` records that dependency, so deploying the owning config alone later asks for confirmation instead of silently turning publishing off — it fails outright in a non-interactive environment. Set `publishEvents: true` on the type to keep it on regardless of which configs take part.
+
 #### GraphQL Operations
 
 Control which GraphQL operations (`create`, `update`, `delete`, `read`) are exposed for a type. All operations are enabled by default.
@@ -595,7 +597,7 @@ export default defineConfig({
 });
 ```
 
-This default is re-evaluated on every `tailor-sdk deploy`, so changing it also updates types that already exist on the platform, not only newly created ones.
+This default is re-evaluated on every `tailor deploy`, so changing it also updates types that already exist on the platform, not only newly created ones.
 
 ### Field Extraction (`pickFields` / `omitFields`)
 

package/docs/services/workflow.md

@@ -201,6 +201,36 @@ export default createWorkflow({
 });
 ```
 
+## Execution Events
+
+Workflows can publish execution lifecycle events for executors. When an executor subscribes to a workflow's events, `deploy` enables publishing automatically. A `workflowExecution*` trigger enables it on the workflow, and a `workflowJobExecution*` trigger enables it on every job that workflow runs. See [Workflow Execution Triggers](./executor.md#workflow-execution-triggers).
+
+Publishing follows the subscription in both directions: removing the last subscribing trigger turns it back off on the next `deploy`.
+
+Set `publishEvents` explicitly to pin the value instead. Use `true` to publish workflow-level events with no subscribing executor:
+
+```typescript
+export default createWorkflow({
+  name: "order-processing",
+  mainJob: processOrder,
+  publishEvents: true,
+});
+```
+
+A job takes the same field for its own execution events:
+
+```typescript
+export const processOrder = createWorkflowJob({
+  name: "process-order",
+  publishEvents: true,
+  body: async () => ({ processed: true }),
+});
+```
+
+Use `false` to keep publishing off. `deploy` fails if an executor subscribes to events the value opts out of, so the subscription cannot silently go unfulfilled.
+
+**Subscribing from another config:** an executor in another config auto-enables publishing the same way, as long as both configs take part in the same `deploy` (`--config a,b`). The workflow a `workflowExecution*` or `workflowJobExecution*` trigger names must be declared by a config in the run; `deploy` fails otherwise rather than creating an executor whose events never arrive. `deploy` records the dependency on the workflow itself, so deploying that config alone later asks for confirmation instead of silently turning publishing off. Declaring `publishEvents` clears the record: a declared value no longer depends on which configs are deployed together, so there is nothing left to warn about.
+
 ## Wait Points
 
 Wait points allow a workflow job to suspend execution and wait for an external signal before resuming. This enables human-in-the-loop patterns such as approvals, reviews, and manual confirmations.
@@ -357,7 +387,7 @@ Execution policies apply a per-key concurrency cap to workflow job function disp
 
 ### Declaring Policies
 
-Use `defineWorkflowExecutionPolicies` with a builder callback. Property names supply the workspace-unique name and default key prefix verbatim, matching the mental model of `defineWaitPoints`. Override `name` or `key` in the body when the property identifier is not valid execution policy grammar or the key prefix needs to differ. Set `matchType: "prefix"` to register the prefix as a wildcard that matches every dispatch key starting with it (the default, `"exact"`, matches only a dispatch key equal to it).
+Use `defineWorkflowExecutionPolicies` with a builder callback. Property names supply the workspace-unique name and default key prefix verbatim, matching the mental model of `createWaitPoints`. Override `name` or `key` in the body when the property identifier is not valid execution policy grammar or the key prefix needs to differ. Set `matchType: "prefix"` to register the prefix as a wildcard that matches every dispatch key starting with it (the default, `"exact"`, matches only a dispatch key equal to it).
 
 ```typescript
 import { defineWorkflowExecutionPolicies } from "@tailor-platform/sdk";
@@ -401,7 +431,7 @@ An exact-key policy applies to dispatches whose runtime key equals the policy ke
 
 ### Referencing a Policy from a Workflow
 
-Pass the runtime key through the `executionPolicyKey` option on `job.start()` or `tailor.workflow.startJobFunction()`. For exact-key policies, use `<policy>.key` directly — it's typed so only a value that came from a declared policy can be passed. For wildcard policies (`matchType: "prefix"`), there is no `<policy>.key` — call `<policy>.keyFor(suffix)` to build the concrete key. `keyFor` joins the prefix and suffix with `.` by default; override it with `separator` — the second argument to `defineWorkflowExecutionPolicies` (applies to every policy in the group), or a `def` field on a single `defineWorkflowExecutionPolicy`.
+Pass the runtime key through the `executionPolicyKey` option on `job.start()` or `tailor.workflow.execJobFunction()`. For exact-key policies, use `<policy>.key` directly — it's typed so only a value that came from a declared policy can be passed. For wildcard policies (`matchType: "prefix"`), there is no `<policy>.key` — call `<policy>.keyFor(suffix)` to build the concrete key. `keyFor` joins the prefix and suffix with `.` by default; override it with `separator` — the second argument to `defineWorkflowExecutionPolicies` (applies to every policy in the group), or a `def` field on a single `defineWorkflowExecutionPolicy`.
 
 ```typescript
 import { createWorkflowJob } from "@tailor-platform/sdk";
@@ -427,7 +457,7 @@ export const mainJob = createWorkflowJob({
 });
 ```
 
-The same `executionPolicyKey` option is available on `tailor.workflow.startJobFunction(name, args, options)` for jobs invoked by name.
+The same `executionPolicyKey` option is available on `tailor.workflow.execJobFunction(name, args, options)` for jobs invoked by name.
 
 ## Starting a Workflow from a Resolver
 

package/docs/testing.md

@@ -26,7 +26,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`, `mockAigateway` — corresponding platform API mocks
+- `mockSecretmanager`, `mockAuthconnection`, `mockIdp`, `mockFile`, `mockIconv`, `mockAigateway`, `mockLogger` — 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.
 
@@ -63,7 +63,7 @@ export default defineConfig({
 
 ### Acquiring mocks with `using`
 
-Each mock controller (`mockTailordb`, `mockWorkflow`, `mockSecretmanager`, `mockAuthconnection`, `mockIdp`, `mockFile`, `mockIconv`, `mockAigateway`) is a **factory function**. Acquire it inside a test with a [`using` declaration](https://github.com/tc39/proposal-explicit-resource-management) — its state is reset automatically when the test scope exits, so you no longer need `beforeEach(() => mock.reset())`:
+Each mock controller (`mockTailordb`, `mockWorkflow`, `mockSecretmanager`, `mockAuthconnection`, `mockIdp`, `mockFile`, `mockIconv`, `mockAigateway`, `mockLogger`) is a **factory function**. Acquire it inside a test with a [`using` declaration](https://github.com/tc39/proposal-explicit-resource-management) — its state is reset automatically when the test scope exits, so you no longer need `beforeEach(() => mock.reset())`:
 
 ```typescript
 import { mockTailordb } from "@tailor-platform/sdk/vitest";
@@ -166,7 +166,7 @@ test("workflow starts jobs", async () => {
 });
 ```
 
-Unconfigured definition mocks continue to run their real implementations. The lower-level `startJobFunction`, `startWorkflow`, `resumeWorkflowExecution`, `wait`, and `resolve` mocks and the existing `setJobHandler`, `enqueueResult`, `enqueueResults`, and call-record helpers remain available.
+Unconfigured definition mocks continue to run their real implementations. The lower-level `execJobFunction`, `startWorkflow`, `resumeWorkflowExecution`, `wait`, and `resolve` mocks and the existing `setJobHandler`, `enqueueResult`, `enqueueResults`, and call-record helpers remain available.
 
 Use `waitPoint(definition)` for typed wait-point control:
 
@@ -321,6 +321,27 @@ test("resolves an AI Gateway URL", async () => {
 
 Calling `get` for a name that has not been registered throws. `setUrls` remains available when replacing the complete URL fixture.
 
+### Logger Mock
+
+Each method is a `vi.fn`, so assert on it directly. `calls` returns the emitted `debug`/`info`/`warn`/`error` entries in order.
+
+```typescript
+import { mockLogger } from "@tailor-platform/sdk/vitest";
+
+test("logs the processed order", () => {
+  using logger = mockLogger();
+
+  tailor.logger.info("order processed", { orderId: "o-1" });
+
+  expect(logger.info).toHaveBeenCalledWith("order processed", { orderId: "o-1" });
+  expect(logger.calls).toEqual([
+    { severity: "info", message: "order processed", attributes: { orderId: "o-1" } },
+  ]);
+});
+```
+
+Without an explicit `mockLogger()`, `tailor.logger.*` calls are no-ops in the `tailor-runtime` environment (they neither throw nor record).
+
 ### Loading Secrets from Config
 
 Pass a config path to load `defineSecretManager()` values into the mock:
@@ -407,14 +428,16 @@ Stub the global `tailordb.Client` and queue raw query results in order. Best for
 
 > If you are running with the [`tailor-runtime` Vitest environment](#runtime-environment-emulation-beta), acquire `using db = mockTailordb()` to install and drive the mock `tailordb.Client` instead of `vi.stubGlobal()`.
 
+> The example below uses `aroundAll` / `aroundEach`, which require Vitest ≥ 4.1.
+
 ```typescript
-import { afterAll, afterEach, beforeAll, describe, expect, test, vi } from "vitest";
+import { aroundAll, aroundEach, describe, expect, test, vi } from "vitest";
 import resolver from "../src/resolver/incrementUserAge";
 
 describe("incrementUserAge resolver", () => {
   const mockQueryObject = vi.fn();
 
-  beforeAll(() => {
+  aroundAll(async (runSuite) => {
     vi.stubGlobal("tailordb", {
       Client: vi.fn(
         class {
@@ -424,9 +447,13 @@ describe("incrementUserAge resolver", () => {
         },
       ),
     });
+    await runSuite();
+    vi.unstubAllGlobals();
+  });
+  aroundEach(async (runTest) => {
+    await runTest();
+    mockQueryObject.mockReset();
   });
-  afterAll(() => vi.unstubAllGlobals());
-  afterEach(() => mockQueryObject.mockReset());
 
   test("increments age inside a transaction", async () => {
     // BEGIN → SELECT → UPDATE → COMMIT

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.0.0-next.9",
+  "version": "2.0.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -140,12 +140,17 @@
       "types": "./dist/runtime/aigateway.d.mts",
       "import": "./dist/runtime/aigateway.mjs",
       "default": "./dist/runtime/aigateway.mjs"
+    },
+    "./runtime/logger": {
+      "types": "./dist/runtime/logger.d.mts",
+      "import": "./dist/runtime/logger.mjs",
+      "default": "./dist/runtime/logger.mjs"
     }
   },
   "dependencies": {
-    "@0no-co/graphql.web": "1.3.2",
+    "@0no-co/graphql.web": "1.3.3",
     "@badgateway/oauth2-client": "3.3.1",
-    "@bufbuild/protobuf": "2.12.1",
+    "@bufbuild/protobuf": "2.13.0",
     "@bufbuild/protovalidate": "1.2.0",
     "@connectrpc/connect": "2.1.2",
     "@connectrpc/connect-node": "2.1.2",
@@ -154,11 +159,13 @@
     "@jridgewell/trace-mapping": "0.3.31",
     "@napi-rs/keyring": "1.3.0",
     "@opentelemetry/api": "1.9.1",
-    "@opentelemetry/exporter-trace-otlp-proto": "0.220.0",
-    "@opentelemetry/resources": "2.9.0",
-    "@opentelemetry/sdk-trace-node": "2.9.0",
+    "@opentelemetry/exporter-trace-otlp-proto": "0.221.0",
+    "@opentelemetry/resources": "2.10.0",
+    "@opentelemetry/sdk-trace-node": "2.10.0",
     "@opentelemetry/semantic-conventions": "1.43.0",
-    "@oxc-project/types": "0.139.0",
+    "@oxc-project/types": "0.142.0",
+    "@secretlint/core": "13.0.4",
+    "@secretlint/secretlint-rule-preset-recommend": "13.0.4",
     "@standard-schema/spec": "1.1.0",
     "@tailor-platform/function-kysely-tailordb": "0.1.3",
     "@toiroakr/lines-db": "0.10.1",
@@ -168,48 +175,48 @@
     "chalk": "5.6.2",
     "confbox": "0.2.4",
     "date-fns": "4.4.0",
-    "es-toolkit": "1.49.0",
+    "es-toolkit": "1.50.0",
     "find-up-simple": "1.0.1",
-    "globals": "17.7.0",
+    "get-east-asian-width": "1.6.0",
+    "get-tsconfig": "4.14.0",
+    "globals": "17.8.0",
     "graphql": "17.0.2",
     "inflection": "3.0.2",
-    "kysely": "0.29.3",
+    "kysely": "0.29.4",
     "mime-types": "3.0.2",
     "open": "11.0.0",
-    "oxc-parser": "0.139.0",
-    "p-limit": "7.3.0",
+    "oxc-parser": "0.142.0",
+    "p-limit": "7.3.1",
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.3.1",
-    "politty": "0.11.2",
-    "rolldown": "1.1.5",
+    "politty": "0.11.6",
+    "rolldown": "1.2.0",
     "semver": "7.8.5",
     "sql-highlight": "6.1.0",
     "std-env": "4.2.0",
-    "table": "6.9.0",
     "ts-cron-validator": "1.1.5",
     "type-fest": "5.8.0",
-    "undici": "8.7.0",
     "xdg-basedir": "5.1.0",
     "zod": "4.4.3"
   },
   "devDependencies": {
-    "@opentelemetry/sdk-trace-base": "2.9.0",
+    "@opentelemetry/sdk-trace-base": "2.10.0",
     "@types/mime-types": "3.0.1",
     "@types/node": "24.13.3",
     "@types/semver": "7.7.1",
     "@typescript/native-preview": "7.0.0-dev.20260707.2",
     "@vitest/coverage-v8": "4.1.10",
     "eslint-plugin-zod": "4.7.0",
-    "oxfmt": "0.58.0",
-    "oxlint": "1.73.0",
-    "oxlint-tsgolint": "0.24.0",
+    "oxfmt": "0.61.0",
+    "oxlint": "1.76.0",
+    "oxlint-tsgolint": "7.0.2001",
     "sonda": "0.14.0",
-    "tsdown": "0.22.7",
+    "tsdown": "0.22.14",
     "typescript": "6.0.3",
     "vitest": "4.1.10",
-    "zinfer": "0.2.5",
-    "@tailor-platform/tailor-proto": "^0.0.0"
+    "zinfer": "0.2.7",
+    "@tailor-platform/tailor-proto": "^0.0.1"
   },
   "peerDependencies": {
     "vite": "^6.0.0 || ^7.0.0 || ^8.0.0",
@@ -234,7 +241,7 @@
     "test:coverage": "vitest --coverage",
     "docs:check": "vitest run --project=unit* src/cli/docs.test.ts",
     "docs:update": "POLITTY_DOCS_UPDATE=true vitest run --project=unit* src/cli/docs.test.ts",
-    "build": "tsdown && politty generate-worker --bin dist/cli/index.mjs --program tailor --shell zsh --verify",
+    "build": "tsdown && politty generate-shim --entry ./main.mjs --program tailor && politty generate-worker --bin dist/cli/main.mjs --program tailor --shell zsh --verify",
     "lint": "oxlint --type-aware .",
     "check:public-api-jsdoc": "node --experimental-strip-types scripts/check-public-api-jsdoc.ts",
     "check:zod-isolation": "node --experimental-strip-types scripts/check-zod-isolation.ts",

package/dist/application-CtuzFhg8.mjs

@@ -1,3 +0,0 @@
-import { n as generatePluginFilesIfNeeded, r as loadApplication, t as defineApplication } from "./application-D_oSqto2.mjs";
-
-export { defineApplication, generatePluginFilesIfNeeded };