@tailor-platform/sdk 2.6.0 → 2.8.0

package/docs/cli-reference.md

@@ -386,22 +386,6 @@ Commands for managing crash reports.
 | [crashreport list](./cli/crashreport.md#crashreport-list) | List local crash report files.                 |
 | [crashreport send](./cli/crashreport.md#crashreport-send) | Submit a crash report to help improve the SDK. |
 
-### [Setup Commands](./cli/setup.md)
-
-Commands for setting up project infrastructure.
-
-| Command                                             | Description                                                                                      |
-| --------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
-| [setup](./cli/setup.md#setup)                       | Set up repository automation for your project. (beta)                                            |
-| [setup action](./cli/setup.md#setup-action)         | Generate a per-app composite action for use with setup coordinate (monorepo multi-app deploys).  |
-| [setup branch](./cli/setup.md#setup-branch)         | Generate a branch-target deploy workflow (push to branch triggers deploy).                       |
-| [setup check](./cli/setup.md#setup-check)           | Audit generated workflows for drift against the current config/repo (read-only).                 |
-| [setup coordinate](./cli/setup.md#setup-coordinate) | Generate a coordinator workflow that orchestrates multiple --action-generated composite actions. |
-| [setup delete](./cli/setup.md#setup-delete)         | Delete managed workflow/action file(s) and their .github/tailor.lock entries.                    |
-| [setup deps](./cli/setup.md#setup-deps)             | Generate a dependency update config for Tailor dependency and workflow updates.                  |
-| [setup preview](./cli/setup.md#setup-preview)       | Generate a preview workflow (PR open/sync triggers deploy to a per-PR workspace).                |
-| [setup tag](./cli/setup.md#setup-tag)               | Generate a tag-target deploy workflow (tag push triggers deploy).                                |
-
 ### [Upgrade Commands](./cli/upgrade.md)
 
 Commands for upgrading SDK versions with automated code migration.

package/docs/github-actions.md

@@ -7,6 +7,18 @@ application, including deploy workflows and Renovate configuration.
 > workflow, and the `.github/tailor.lock` schema may change before general
 > availability.
 
+## Installation
+
+The `setup` commands are provided by the `@tailor-platform/sdk-plugin-setup` CLI
+plugin. Install it next to the SDK:
+
+```bash
+npm install -D @tailor-platform/sdk-plugin-setup
+```
+
+The Tailor CLI discovers the plugin automatically from `node_modules/.bin` (or
+your `PATH`). Run `tailor plugin list` to confirm it resolves.
+
 ## Quick start
 
 Run the command from the root of your SDK project (where `tailor.config.ts`

package/docs/services/executor.md

@@ -44,6 +44,23 @@ export default createExecutor({
 });
 ```
 
+### Disabling an Executor
+
+Set `disabled: true` to deploy an executor without letting it run. The definition stays deployed, and the platform skips dispatching jobs to it.
+
+```typescript
+export default createExecutor({
+  name: "user-welcome-paused",
+  disabled: true,
+  trigger: recordCreatedTrigger({ type: user }),
+  operation: { kind: "function", body: async () => {} },
+});
+```
+
+A disabled executor does not count as a subscriber when `deploy` resolves `publishEvents` on the resource its trigger names. Publishing is not enabled on that resource's behalf, and an explicit `publishEvents: false` on it is not rejected. If the resource was publishing only for this executor, the next `deploy` turns publishing back off — so disabling the last subscriber of a shared table changes that table for every config that reads its events.
+
+The trigger is still deployed, so it must still name a resource the deploy declares; a disabled executor whose trigger names nothing fails the deploy exactly as an enabled one does.
+
 ## Trigger Types
 
 ### Record Triggers

package/docs/services/idp.md

@@ -330,7 +330,7 @@ defineIdp("my-idp", {
 });
 ```
 
-**Auto-configuration:** When `publishEvents` is omitted, `deploy` sets it from the executors taking part in the same run: `true` while one of their `idpUser` triggers targets this IdP, and `false` once none does. Removing the last such trigger turns publishing back off on the next `deploy`. Targeting is per-IdP: an executor specifies which IdP it subscribes to via the trigger's `idp` option (required in multi-IdP projects). Set the value explicitly to override:
+**Auto-configuration:** When `publishEvents` is omitted, `deploy` sets it from the executors taking part in the same run: `true` while one of their `idpUser` triggers targets this IdP, and `false` once none does. Removing the last such trigger turns publishing back off on the next `deploy`, as does disabling the last executor that carries one. Targeting is per-IdP: an executor specifies which IdP it subscribes to via the trigger's `idp` option (required in multi-IdP projects). Set the value explicitly to override:
 
 - `publishEvents: true`: always publish events.
 - `publishEvents: false`: never publish events. `deploy` rejects this with an error if an `idpUser` trigger taking part in the same run targets this IdP — either remove `publishEvents: false` or remove the matching trigger.

package/docs/services/resolver.md

@@ -310,7 +310,7 @@ createResolver({
 
 **Use cases:**
 
-1. **Auto-detection (recommended)**: Don't set `publishEvents` - `deploy` enables it while an executor taking part in the same run needs it
+1. **Auto-detection (recommended)**: Don't set `publishEvents` - `deploy` enables it while an executor taking part in the same run needs it. An executor declared with `disabled: true` never runs, so it does not count
 
    ```typescript
    // publishEvents is automatically enabled because an executor uses this resolver

package/docs/services/tailordb-migration.md

@@ -757,6 +757,18 @@ The migration script runs in a single transaction. For tables with many rows:
 - Long-running transactions can hit platform timeouts and hold locks. For very large backfills, consider splitting the work across multiple migrations, each operating on a subset.
 - Add `LIMIT` and resumability (idempotent `where` clauses) so a re-run after a transient failure converges.
 
+### Migrations that take longer than a minute
+
+Migration scripts run as workflow jobs, so they are not bound by the 60-second
+limit that applies to synchronous script execution. `tailor deploy` waits for
+the migration and reports its logs as usual. Execution time is still bounded —
+a workflow job has its own, far longer, execution-time limit.
+
+The script still runs in a single transaction, so the guidance above about
+locks and transaction size continues to apply — prefer splitting a very large
+backfill across several migrations over holding one transaction open for a
+long time.
+
 ## Testing Migrations Locally
 
 ### Unit-testing migrate.ts

package/docs/services/tailordb.md

@@ -69,8 +69,8 @@ db.table("User", "User in the system", {
 | `db.float()`                      | Float    | number         |
 | [`db.decimal()`](#decimal-fields) | Decimal  | string         |
 | `db.bool()`                       | Boolean  | boolean        |
-| `db.date()`                       | Date     | string         |
-| `db.datetime()`                   | DateTime | string \| Date |
+| `db.date()`                       | Date     | Date \| string |
+| `db.datetime()`                   | DateTime | Date \| string |
 | `db.time()`                       | Time     | string         |
 | `db.uuid()`                       | UUID     | string         |
 | [`db.enum()`](#enum-fields)       | Enum     | string         |
@@ -519,6 +519,8 @@ db.table("User", {
 - When `publishEvents: true`, record creation/update/deletion events are published
 - When not specified, `deploy` sets it from the executors taking part in the same run: `true` while one of them uses this table 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 table, `deploy` fails
+- An executor declared with `disabled: true` never runs, so it does not count as using the table
+- While a `deploy` applies pending migrations, every table in the migrating namespace is read-only: create, update, delete, and bulk-upsert operations are disabled while the existing read setting is preserved. Record event publishing is also switched off so a migration script's writes do not reach executors from the previous deploy. After success, the configured settings take effect. If a later migration fails, settings from the last confirmed checkpoint are restored; an uncommitted migration restores existing tables' prior settings and leaves its newly created tables restricted until a successful retry. Restoration is skipped if the checkpoint number or migration history changed concurrently, or if checkpoint ownership cannot be verified. A table left behind by a failed post-checkpoint deletion also remains read-only for manual recovery
 
 **Use cases:**
 
@@ -563,6 +565,8 @@ db.table("User", {
 
 Control which GraphQL operations (`create`, `update`, `delete`, `read`) are exposed for a table. All operations are enabled by default.
 
+While a `deploy` applies pending migrations, every GraphQL operation — `create`, `update`, `delete`, `read`, and bulk upsert — is switched off across the migrating namespace, so nothing reads or writes an intermediate schema. After success, the configured operations take effect. If a later migration fails, operations from the last confirmed checkpoint are restored; an uncommitted migration restores existing tables' prior operations and leaves its newly created tables restricted until a successful retry. Restoration is skipped if the checkpoint number or migration history changed concurrently.
+
 ```typescript
 db.table("Order", {
   status: db.string(),

package/docs/services/workflow.md

@@ -208,7 +208,7 @@ export default createWorkflow({
 
 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`.
+Publishing follows the subscription in both directions: removing the last subscribing trigger turns it back off on the next `deploy`, as does disabling the last executor that carries one.
 
 Set `publishEvents` explicitly to pin the value instead. Use `true` to publish workflow-level events with no subscribing executor:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.6.0",
+  "version": "2.8.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -149,15 +149,14 @@
     }
   },
   "dependencies": {
-    "@0no-co/graphql.web": "1.3.3",
+    "@0no-co/graphql.web": "1.3.4",
     "@badgateway/oauth2-client": "3.3.1",
     "@bufbuild/protobuf": "2.14.0",
     "@bufbuild/protovalidate": "1.2.0",
     "@connectrpc/connect": "2.1.2",
     "@connectrpc/connect-node": "2.1.2",
-    "@croct/json5-parser": "0.2.2",
-    "@inquirer/core": "11.2.1",
-    "@inquirer/prompts": "8.5.2",
+    "@inquirer/core": "12.0.0",
+    "@inquirer/prompts": "8.6.0",
     "@jridgewell/trace-mapping": "0.3.31",
     "@napi-rs/keyring": "1.3.0",
     "@opentelemetry/api": "1.9.1",
@@ -165,7 +164,7 @@
     "@opentelemetry/resources": "2.10.0",
     "@opentelemetry/sdk-trace-node": "2.10.0",
     "@opentelemetry/semantic-conventions": "1.43.0",
-    "@oxc-project/types": "0.144.0",
+    "@oxc-project/types": "0.147.0",
     "@secretlint/core": "13.0.4",
     "@secretlint/secretlint-rule-preset-recommend": "13.0.4",
     "@standard-schema/spec": "1.1.0",
@@ -183,17 +182,16 @@
     "globals": "17.11.0",
     "graphql": "17.0.2",
     "inflection": "3.0.2",
-    "json5": "2.2.3",
     "kysely": "0.29.5",
     "mime-types": "3.0.2",
     "open": "11.0.1",
-    "oxc-parser": "0.144.0",
+    "oxc-parser": "0.147.0",
     "p-limit": "7.3.1",
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.3.1",
     "politty": "0.11.9",
-    "rolldown": "1.2.4",
+    "rolldown": "1.2.5",
     "semver": "7.8.5",
     "sql-highlight": "6.1.0",
     "std-env": "4.2.0",
@@ -204,22 +202,22 @@
   },
   "devDependencies": {
     "@opentelemetry/sdk-trace-base": "2.10.0",
+    "@tailor-platform/shared": "^0.0.0",
+    "@tailor-platform/tailor-proto": "^0.0.1",
     "@types/mime-types": "3.0.1",
     "@types/node": "24.13.3",
     "@types/semver": "7.8.0",
     "@typescript/native-preview": "7.0.0-dev.20260707.2",
-    "@vitest/coverage-v8": "4.1.10",
-    "eslint-plugin-zod": "4.9.1",
-    "oxfmt": "0.63.0",
-    "oxlint": "1.78.0",
+    "@vitest/coverage-v8": "4.1.11",
+    "eslint-plugin-zod": "4.10.0",
+    "oxfmt": "0.65.0",
+    "oxlint": "1.80.0",
     "oxlint-tsgolint": "7.0.2001",
     "sonda": "0.14.0",
     "tsdown": "0.22.14",
     "typescript": "6.0.3",
-    "vitest": "4.1.10",
-    "zinfer": "0.2.8",
-    "@tailor-platform/shared": "^0.0.0",
-    "@tailor-platform/tailor-proto": "^0.0.1"
+    "vitest": "4.1.11",
+    "zinfer": "0.2.8"
   },
   "peerDependencies": {
     "@electric-sql/pglite": ">=0.2.0",

package/dist/application-CNeOcaLc.mjs

@@ -1 +0,0 @@
-import{n as e,t}from"./application-CmXOqTaK.mjs";export{t as defineApplication,e as generatePluginFilesIfNeeded};