@tailor-platform/sdk 2.32.0 → 2.34.0

package/docs/cli/application.md

@@ -270,7 +270,8 @@ Pass the global `--json` / `-j` flag to get machine-readable output.
 
 - `summary` — counts of each change type. `forcedBySdkVersion` counts the updates forced by the SDK version, which are also included in `update`.
 - `changes` — planned resource changes, each with `action`, `name`, and optional `labels` / `namespace`. An update forced by the SDK version also has `forcedBySdkVersion: true`.
-- `warnings` — resources not in config (`type: "unmanaged"`) or secrets with missing values (`type: "skippedSecret"`). Unmanaged resources require confirmation in apply mode (apply is cancelled if declined); skipped secrets are non-blocking.
+- `warnings` — resources not in config (`type: "unmanaged"`), secrets with missing values (`type: "skippedSecret"`), or applications recorded as depending on this deploy but missing from it (`type: "missingDependentApp"`). Unmanaged resources and missing dependent applications require confirmation in apply mode (apply is cancelled if declined); skipped secrets are non-blocking.
+  - A `missingDependentApp` entry names the missing application's `appId`, the `reason` it depends on this deploy, and the resource whose event publishing turns off when applying without it (`resourceType` and `name`, plus `namespace` for a TailorDB table or resolver). An entry about a workflow's jobs rather than the workflow itself has `scope: "jobs"`.
 - `conflicts` — resources owned by another application that conflict with the current config. Require confirmation in apply mode; apply is cancelled if declined.
 - `resourceType` in `warnings` and `conflicts` is a stable identifier of the resource kind, such as `executor`, `tailordb.service`, or `secret.secret`. The human-readable plan shows a display name instead.
 

package/docs/cli/tailordb.md

@@ -286,7 +286,7 @@ See [Global Options](../cli-reference.md#global-options) for options available t
 
 **Notes**
 
-Every local migration file is checked for a compatible format version, and deployed migration history IDs must match the local baseline. Compatibility errors, history mismatches, and metadata lookup failures are reported per namespace and make the command exit non-zero; only a not-yet-deployed namespace is treated as having no applied migrations.
+Local migration files are checked for a valid layout (numbering and required files in each migration directory) and a compatible format version, and deployed migration history IDs must match the local baseline. Invalid or incompatible files, history mismatches, and metadata lookup failures are reported per namespace and make the command exit non-zero; only a not-yet-deployed namespace is treated as having no applied migrations.
 
 #### tailordb migration sync
 

package/docs/cli/user.md

@@ -70,10 +70,10 @@ See [Global Options](../cli-reference.md#global-options) for options available t
 
 **Commands**
 
-| Command                       | Description                                                                           |
-| ----------------------------- | ------------------------------------------------------------------------------------- |
-| [`auth status`](#auth-status) | Show the active Tailor Platform authentication status without printing tokens.        |
-| [`auth token`](#auth-token)   | Print a valid Tailor Platform access token to stdout, refreshing it first if expired. |
+| Command                       | Description                                                                                                  |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| [`auth status`](#auth-status) | Show the active Tailor Platform authentication status without printing tokens.                               |
+| [`auth token`](#auth-token)   | Print a valid Tailor Platform access token to stdout, refreshing it first if it expires within five minutes. |
 
 ### auth status
 
@@ -95,7 +95,7 @@ See [Global Options](../cli-reference.md#global-options) for options available t
 
 ### auth token
 
-Print a valid Tailor Platform access token to stdout, refreshing it first if expired.
+Print a valid Tailor Platform access token to stdout, refreshing it first if it expires within five minutes.
 
 **Usage**
 

package/docs/cli/workspace.md

@@ -253,7 +253,7 @@ Manage when a workspace becomes prunable.
 **Usage**
 
 ```
-tailor workspace ttl [command]
+tailor workspace ttl <command>
 ```
 
 See [Global Options](../cli-reference.md#global-options) for options available to all commands.

package/docs/cli-reference.md

@@ -20,8 +20,8 @@ tailor <command> [options]
 | ------------------------------------------- | ----- | --------------------------------------------------- | -------- | ------- | -------------------- |
 | `--env-file <ENV_FILE>`                     | `-e`  | Path to the environment file (error if not found)   | No       | -       | -                    |
 | `--env-file-if-exists <ENV_FILE_IF_EXISTS>` | -     | Path to the environment file (ignored if not found) | No       | -       | -                    |
-| `--verbose`                                 | -     | Enable verbose logging                              | No       | `false` | -                    |
-| `--json`                                    | `-j`  | Output as JSON                                      | No       | `false` | `TAILOR_JSON_OUTPUT` |
+| `--verbose` / `--no-verbose`                | -     | Enable verbose logging                              | No       | `false` | -                    |
+| `--json` / `--no-json`                      | `-j`  | Output as JSON                                      | No       | `false` | `TAILOR_JSON_OUTPUT` |
 
 ### Progress and Detailed Logs
 
@@ -82,13 +82,13 @@ unexpected argument, or an option value that fails validation (including one set
 environment variable), and `1` for other failures, including checks a command makes after reading
 its arguments. A command that only warns about an unknown option or an extra argument keeps
 running. Cancelling an interactive prompt exits with `130`, and a CLI plugin exits with its own
-code. A command group run without a subcommand, such as `tailor` or `tailor tailordb`, can exit
-with `0` after printing its help or a warning even when an option is unknown or its value is
-invalid, so name the subcommand to rely on `2`.
+code.
 
 Authentication failures distinguish missing credentials (`AUTH_TOKEN_NOT_FOUND`), a missing saved
 user (`AUTH_USER_NOT_FOUND`), an expired token (`AUTH_TOKEN_EXPIRED`), and a failed token refresh
-(`AUTH_TOKEN_REFRESH_FAILED`). Login recovery preserves the selected profile. For saved identities,
+(`AUTH_TOKEN_REFRESH_FAILED`). `CONFIG_LOCK_TIMEOUT` means another `tailor` command kept the saved
+credentials locked for too long; `error.context.lockPath` names the lock file to delete if no other
+command is running. Login recovery preserves the selected profile. For saved identities,
 the next step opens login help so you can reuse the original browser or machine-user login method. Permission and
 connection failures include guidance in `error.suggestion`; API failures also identify the operation
 and affected resources in `error.context`.
@@ -107,7 +107,8 @@ excluded from that list.
 Use `--verbose` to include debug diagnostics and error stack traces. `DEBUG=true` or
 `RUNNER_DEBUG=1` also enables verbose output, including stacks in JSON errors. GitHub Actions
 sets `RUNNER_DEBUG=1` when debug logging is enabled, so the same command automatically includes
-these details in a debug run. These settings do not enable JSON output; pass `--json` separately.
+these details in a debug run. `--no-verbose` turns verbose output off even when these are set.
+These settings do not enable JSON output; pass `--json` separately.
 
 Capture the original failure's stderr and exit code before retrying. Failures before the CLI starts,
 a rejected `--json` or `TAILOR_JSON_OUTPUT` value, argument errors in the bundled CLI plugins, and
@@ -300,7 +301,7 @@ the plugin does not need to re-implement authentication or re-resolve the active
 The token, workspace ID, and user are best-effort: whatever the current context can resolve is injected,
 and auth-free plugins still run when you are not logged in. A long-running plugin (or one started on its
 own) can obtain a fresh token at any time with `tailor auth token`, which prints a valid access token to
-stdout, refreshing it first if it has expired.
+stdout, refreshing it first if it expires within five minutes.
 
 ## Commands
 
@@ -362,23 +363,23 @@ Run ad-hoc SQL/GraphQL queries or enter the interactive REPL.
 
 Commands for authentication and user management.
 
-| Command                                          | Description                                                                           |
-| ------------------------------------------------ | ------------------------------------------------------------------------------------- |
-| [login](./cli/user.md#login)                     | Login to Tailor Platform.                                                             |
-| [logout](./cli/user.md#logout)                   | Logout from Tailor Platform.                                                          |
-| [auth](./cli/user.md#auth)                       | Authentication helpers for scripts and plugins.                                       |
-| [auth status](./cli/user.md#auth-status)         | Show the active Tailor Platform authentication status without printing tokens.        |
-| [auth token](./cli/user.md#auth-token)           | Print a valid Tailor Platform access token to stdout, refreshing it first if expired. |
-| [user](./cli/user.md#user)                       | Manage Tailor Platform users.                                                         |
-| [user current](./cli/user.md#user-current)       | Show current user.                                                                    |
-| [user list](./cli/user.md#user-list)             | List all users.                                                                       |
-| [user pat](./cli/user.md#user-pat)               | Manage personal access tokens.                                                        |
-| [user pat create](./cli/user.md#user-pat-create) | Create a new personal access token.                                                   |
-| [user pat delete](./cli/user.md#user-pat-delete) | Delete a personal access token.                                                       |
-| [user pat list](./cli/user.md#user-pat-list)     | List all personal access tokens.                                                      |
-| [user pat update](./cli/user.md#user-pat-update) | Update a personal access token (delete and recreate).                                 |
-| [user switch](./cli/user.md#user-switch)         | Set current user.                                                                     |
-| [user update](./cli/user.md#user-update)         | Set the current user's default organization and folder for new workspaces.            |
+| Command                                          | Description                                                                                                  |
+| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
+| [login](./cli/user.md#login)                     | Login to Tailor Platform.                                                                                    |
+| [logout](./cli/user.md#logout)                   | Logout from Tailor Platform.                                                                                 |
+| [auth](./cli/user.md#auth)                       | Authentication helpers for scripts and plugins.                                                              |
+| [auth status](./cli/user.md#auth-status)         | Show the active Tailor Platform authentication status without printing tokens.                               |
+| [auth token](./cli/user.md#auth-token)           | Print a valid Tailor Platform access token to stdout, refreshing it first if it expires within five minutes. |
+| [user](./cli/user.md#user)                       | Manage Tailor Platform users.                                                                                |
+| [user current](./cli/user.md#user-current)       | Show current user.                                                                                           |
+| [user list](./cli/user.md#user-list)             | List all users.                                                                                              |
+| [user pat](./cli/user.md#user-pat)               | Manage personal access tokens.                                                                               |
+| [user pat create](./cli/user.md#user-pat-create) | Create a new personal access token.                                                                          |
+| [user pat delete](./cli/user.md#user-pat-delete) | Delete a personal access token.                                                                              |
+| [user pat list](./cli/user.md#user-pat-list)     | List all personal access tokens.                                                                             |
+| [user pat update](./cli/user.md#user-pat-update) | Update a personal access token (delete and recreate).                                                        |
+| [user switch](./cli/user.md#user-switch)         | Set current user.                                                                                            |
+| [user update](./cli/user.md#user-update)         | Set the current user's default organization and folder for new workspaces.                                   |
 
 ### [Organization Commands](./cli/organization.md)
 

package/docs/configuration.md

@@ -64,9 +64,9 @@ export default defineConfig({
 
 Entries are only added or overwritten. An entry removed from the config keeps its last deployed value on the platform, and labels the config does not name are left untouched. Because those retained labels count towards the platform's limit of 20 labels per resource, `deploy` reports the overflow and stops before changing the application when the labels it would leave behind exceed that limit. The labels are written when the application itself is deployed, so a config with no TailorDB, Resolver, IdP, or Auth service has no application to carry them.
 
-**Build Options**: `buildOptions` groups the settings that control how resolvers, executors, workflow jobs, and other functions are bundled: `logLevel` (below), `inlineSourcemap` (whether bundled functions embed an inline sourcemap for readable error stack traces; default `true`), `inlineSourcemapDependencySources` (below), `allowedRuntimeGlobals` (see [Node-only globals](#node-only-globals)), and `treeshake` (see [Removing unused code](#removing-unused-code)). The top-level `logLevel` and `inlineSourcemap` fields still work but are deprecated; `tailor upgrade` moves them into `buildOptions`. Setting the same option both at the top level and in `buildOptions` is rejected.
+**Build Options**: `buildOptions` groups the settings that control how resolvers, executors, workflow jobs, and other functions are bundled: `logLevel` (below), `inlineSourcemap` (whether bundled functions embed an inline sourcemap for readable error stack traces; default `true`), `inlineSourcemapDependencySources` and `inlineSourcemapProjectSources` (below), `allowedRuntimeGlobals` (see [Node-only globals](#node-only-globals)), and `treeshake` (see [Removing unused code](#removing-unused-code)). The top-level `logLevel` and `inlineSourcemap` fields still work but are deprecated; `tailor upgrade` moves them into `buildOptions`. Setting the same option both at the top level and in `buildOptions` is rejected.
 
-**Sourcemap Sources** (`buildOptions.inlineSourcemapDependencySources`): Whether the inline sourcemap embeds the source text of installed packages, that is, everything under `node_modules`. The default is `false`: only your own source files are embedded, which makes bundled functions much smaller. Error positions in stack traces resolve to the original files and lines either way. With the default, `tailor function run` and `tailor function logs` show the code snippet for a frame inside an installed package from the package's file on your machine, so the snippet is missing when that file is not installed locally (for `tailor function logs`, run it from the project directory you deployed from). Set it to `true` to embed the source text of installed packages as well, or to a list of package names such as `["kysely", "@scope/lib"]` to embed only those packages. A listed package's own dependencies are not embedded unless they are listed too. It has no effect when `inlineSourcemap` is `false`.
+**Sourcemap Sources** (`buildOptions.inlineSourcemapDependencySources`): Whether the inline sourcemap embeds the source text of installed packages, that is, everything under `node_modules`. The default is `false`: only your own source files are embedded, which makes bundled functions much smaller. Error positions in stack traces resolve to the original files and lines either way. With the default, `tailor function run` and `tailor function logs` show the code snippet for a frame inside an installed package from the package's file on your machine, so the snippet is missing when that file is not installed locally (for `tailor function logs`, run it from the project directory you deployed from). Set it to `true` to embed the source text of installed packages as well, or to a list of package names such as `["kysely", "@scope/lib"]` to embed only those packages. A listed package's own dependencies are not embedded unless they are listed too. Files under `node_modules` that belong to no package, such as a generated client in `node_modules/.prisma`, are embedded only when the option is `true`. It has no effect when `inlineSourcemap` is `false`.
 
 ```typescript
 export default defineConfig({
@@ -79,6 +79,17 @@ export default defineConfig({
 
 This is a bundle-time setting. It affects newly bundled deployments; already deployed functions keep the sourcemap they were deployed with until they are redeployed.
 
+**Project Sourcemap Sources** (`buildOptions.inlineSourcemapProjectSources`): Which of your own source files embed their text in the inline sourcemap. By default all of them do. `include` and `exclude` are globs relative to the directory containing your config file, written without a leading `./` (a `./` prefix is ignored). Only files matching `include` (all files when omitted) and not matching `exclude` keep their text. `**` does not match a dot-directory such as `src/.cache`. Files under `node_modules` are controlled by `inlineSourcemapDependencySources` instead. Error positions still resolve to the original files and lines, but `tailor function run` shows no code snippet for a frame in a file whose text is left out. It has no effect when `inlineSourcemap` is `false`.
+
+```typescript
+export default defineConfig({
+  name: "my-app",
+  buildOptions: {
+    inlineSourcemapProjectSources: { exclude: ["src/generated/**"] },
+  },
+});
+```
+
 **Log Level** (`buildOptions.logLevel`): Controls which `console.*` and `logger.*` (from `@tailor-platform/sdk/runtime`) calls are kept when deployment functions are bundled. Supported values are `"DEBUG"`, `"INFO"`, `"WARN"`, `"ERROR"`, and `"SILENT"`. The default is `"DEBUG"` and keeps all calls. `console.log` is treated as a DEBUG-level call (matching the platform's OpenTelemetry severity mapping), so it is dropped at `"INFO"` and above, alongside `console.debug` and `logger.debug`. `logger.setAttributes` has no severity and is never dropped, regardless of `logLevel`. For production deployments, use `"WARN"` to keep warn/error calls while dropping debug, log, and info calls:
 
 ```typescript

package/docs/github-actions.md

@@ -249,6 +249,29 @@ For a preview target, the name can be at most 50 characters: each pull request
 gets its own workspace named `<name>-pr-<number>`, which must fit in 63
 characters.
 
+### Preview target (per-pull-request workspace)
+
+The preview target deploys each pull request to its own workspace and deletes
+that workspace when the pull request is closed:
+
+```bash
+tailor setup ci preview --name my-app --region asia-northeast
+```
+
+Fork pull requests are skipped. Every other pull request gets a preview, draft
+pull requests included. `--require` narrows that to one of:
+
+- `--require ready` skips draft pull requests. The preview is deployed when the
+  draft is marked ready for review.
+- `--require label` deploys only pull requests labeled `tailor:preview`. A
+  labeled draft deploys too, because the label asks for the preview.
+
+When `tailor setup update` regenerates a preview target generated before
+`--require` existed, it reads the target as `--require ready`, or as
+`--require label` if it required the label. The first keeps skipping drafts; the
+second now also deploys a labeled draft. To deploy drafts as well, run
+`tailor setup ci preview` again without `--require`.
+
 ## Targeting a workspace
 
 The generated `plan` and `deploy` jobs target a workspace by **id**, read from
@@ -385,8 +408,8 @@ A job that runs `tailor` against the workspace needs the machine-user
 that only uses `app-url`, such as end-to-end tests, does not.
 
 The job is skipped whenever `tailor-preview-deploy` is skipped: when a pull
-request is closed, for draft and fork pull requests, and for unlabeled ones with
-`--require-preview-label`.
+request is closed, for fork pull requests, for draft pull requests with
+`--require ready`, and for unlabeled ones with `--require label`.
 
 A preview workspace expires 7 days (`ttl: 7d` on `tailor-preview-deploy`) after
 the last push to its pull request. When a pull request is closed,
@@ -476,11 +499,11 @@ failed also counts as passing, so list every job of yours whose failure should
 block merging, not only the last one: above, `seed` is listed because `e2e`
 needs it.
 
-With `--require-preview-label`, the preview workflow does not start when a pull
-request is opened, so its check is not reported until the pull request is
-labeled, reopened, or pushed to. A draft pull request skips the preview deploy,
-and marking it ready for review does not start the workflow, so the check that
-passed while it was a draft stays until the next push. Tag workflows have no
+With `--require label`, the preview workflow does not start when a pull request
+is opened, so its check is not reported until the pull request is labeled,
+reopened, or pushed to. With `--require ready`, a draft pull request skips the
+preview deploy and its check passes; marking it ready for review starts the
+workflow, so the deploy and its check follow right away. Tag workflows have no
 such job: they run on tags, not on pull requests.
 
 ### `.github/tailor.lock`
@@ -758,7 +781,7 @@ Before enabling it, note that:
   and validation run, `updatedAt` changes, and executors with
   `recordUpdatedTrigger` fire once per seeded row on every deploy.
 - Every preview deploy deletes the data reviewers added to the preview
-  workspace. That is every push, and with `--require-preview-label` also every
+  workspace. That is every push, and with `--require label` also every
   label added to the pull request, since each one redeploys the preview.
 - A seed failure fails the deploy job and its notification, although the deploy
   itself went through.
@@ -1016,8 +1039,8 @@ targets it reports.
 Workflows generated by `setup ci branch`, `setup ci tag`, and `setup ci preview`
 self-audit: each contains a `tailor-drift-check` step that
 runs the check in CI. Preview workflows run it alongside each preview deploy,
-so pull requests that deploy no preview (drafts, fork PRs, and unlabeled PRs
-in label-triggered mode) skip the check. A single run audits every target
+so pull requests that deploy no preview (drafts with `--require ready`, fork
+PRs, and unlabeled PRs with `--require label`) skip the check. A single run audits every target
 recorded in `.github/tailor.lock`.
 
 Drift findings are advisory by default. Set the repository variable

package/docs/plugin/custom.md

@@ -90,6 +90,40 @@ interface Plugin<TableConfig = unknown, PluginConfig = unknown> {
 | `executors` | `PluginGeneratedExecutor[]`                     | Additional executors to generate                       |
 | `extends`   | `{ fields?: Record<string, TailorAnyDBField> }` | Fields to add to the source table                      |
 
+Resolvers returned by `onTableLoaded` or `onNamespaceLoaded` are loaded, bundled, and deployed to
+the resolver namespace (a `resolver` key in your config) with the same name as the hook's TailorDB
+namespace (a `db` key). These are separate namespaces that only share the name: with
+`db: { main: ... }` and `resolver: { billing: ... }`, generated resolvers go to a `main` resolver
+namespace, not `billing`. If you configure a resolver namespace with that name, generated resolvers
+join its configured files and use its `defaultPermission`. Otherwise, a resolver namespace is created
+automatically. Configure `defaultPermission` to restrict access; without it, generated resolvers are
+accessible to anonymous callers, like regular resolvers with no permission declared. Generating into
+an external resolver namespace or duplicating a resolver name within a namespace fails the build.
+
+For example, a namespace hook can return a query using `t` field builders:
+
+```typescript
+onNamespaceLoaded() {
+  return {
+    resolvers: [{
+      name: "greet",
+      operation: "query",
+      inputFields: { name: t.string() },
+      outputFields: { message: t.string() },
+      body: 'return { message: `Hello, ${context.input.name}!` };',
+    }],
+  };
+}
+```
+
+The `body` string contains JavaScript statements with access to `context.input`, `context.caller`,
+`context.invoker`, and `context.env`. It can use `await` and platform globals, but cannot capture
+plugin-local variables. Embed configuration values as literals with `JSON.stringify` when building
+the string. Field validators must also be self-contained: they can use their arguments and standard
+JavaScript globals, and references to other names are rejected during generation. Input validation and date conversion follow the same rules as regular
+resolvers. Invalid field definitions or JavaScript syntax fail the build with the plugin and namespace
+identified in the error.
+
 Tables in `tables` are validated as complete TailorDB table definitions before registration.
 Fields in `extends.fields` are validated as part of the resulting source table. You can return a
 table builder directly or a structural copy such as `{ ...db.table(...) }`; a copy is accepted as

package/docs/plugin/index.md

@@ -102,6 +102,7 @@ export const plugins = definePlugins(
 Plugins can generate:
 
 - **Tables**: Additional TailorDB tables (e.g., `CustomerHistory`, `Deleted_Customer`)
+- **Resolvers**: Queries and mutations
 - **Executors**: Event handlers triggered by record changes
 - **Field Extensions**: Additional fields added to the source table
 - **Output Files**: TypeScript code and other files via generation-time hooks

package/docs/services/secret.md

@@ -32,6 +32,12 @@ workspace/
     └── analytics-connection-string
 ```
 
+### Reserved Vault Names
+
+Vault names that start with `tailor--` (two hyphens) are reserved in advance for the platform and have no use today. Declaring such a vault in `defineSecretManager()` prints a warning on `tailor deploy` and will become an error in v3. A name that starts with a single `tailor-`, such as `tailor-reports`, is not reserved.
+
+`tailor deploy` also creates a vault named `idp-<namespace>-<client>` for each IdP client of your application. A declared vault with exactly that name is an error, because both would write to the same vault.
+
 ### Secrets
 
 Secrets are key-value pairs stored within a vault. Secret values are encrypted at rest and only accessible at runtime by authorized services.

package/docs/services/staticwebsite.md

@@ -78,7 +78,37 @@ defineStaticWebSite("my-website", {
 
 After deploying, use `tailor staticwebsite domain get <domain>` to check domain status and retrieve the CNAME targets required for DNS configuration.
 
-A domain can be associated with only one workspace at a time. To set custom domains only in the workspace that owns the domain, see [Multi-Environment Configuration](../multi-environment.md#settings-that-belong-to-a-single-environment).
+A domain can be associated with only one workspace at a time. To set custom domains only in the workspace that owns the domain, see [Multi-Environment Configuration](../multi-environment.md#settings-that-belong-to-a-single-environment). To hand a domain to another site or workspace without taking it offline, see [Moving a domain](#moving-a-domain).
+
+### Moving a domain
+
+A domain already serving traffic can be moved to another static website — in this workspace or another one — without downtime, without reissuing its certificate and without changing DNS. The site that currently holds the domain offers it; the receiving site accepts by listing the domain normally.
+
+On the side giving the domain up, replace the plain entry with the destination:
+
+```typescript
+defineStaticWebSite("my-website", {
+  customDomains: [{ domain: "app.example.com", transferTo: { workspaceId: "..." } }],
+});
+```
+
+Deploying opens the offer. On the receiving side, list the domain as usual and deploy:
+
+```typescript
+defineStaticWebSite("new-website", {
+  customDomains: ["app.example.com"],
+});
+```
+
+That deploy completes the move. The next plan on the giving side reports that the domain moved, and the entry should then be deleted — it describes a move that already happened, not ongoing state.
+
+The two deploys must be separate runs, even when both sites live in the same workspace: the receiving side cannot accept an offer that the same run is still opening, and `tailor deploy` says so rather than failing partway.
+
+These rules apply while an offer is open:
+
+- An offer expires after 7 days. Deploying the entry again after that opens a fresh offer.
+- Neither the domain nor the static website holding it can be removed. Change the entry back to a plain string and deploy to withdraw the offer first; `tailor deploy` and `tailor remove` both refuse before changing anything.
+- An offer takes a moment to become ready. Until it is, the receiving side cannot accept it and its deploy is refused; the giving side's plan says so.
 
 ## Type-safe URL References
 

package/docs/services/tailordb/index.md

@@ -218,6 +218,25 @@ const user = db.table("User", {
 });
 ```
 
+A relation can also be set on a field inside `db.object()`. The inner field gets the foreign key constraint only: no index, no unique constraint, and no forward or backward relationship, as with `type: "keyOnly"`.
+
+```typescript
+const order = db.table("Order", {
+  items: db.object(
+    {
+      productId: db.uuid().relation({
+        type: "keyOnly",
+        toward: { table: product },
+      }),
+      quantity: db.int(),
+    },
+    { array: true },
+  ),
+});
+```
+
+A relation inside `db.object()` that points at its own table is not yet handled by `tailor seed apply` or by the data copy a table rename generates. Both write rows in batches, and the platform rejects a row whose parent is in the same or a later batch.
+
 Create relations against different fields using `toward.key`:
 
 ```typescript

package/docs/services/tailordb/migration.md

@@ -96,7 +96,7 @@ A typical change cycle:
      DB types: ./migrations/0001/db.ts
    ```
 
-   If `EDITOR` or `VISUAL` is set, `migrate.ts` opens automatically unless JSON output is enabled.
+   If `EDITOR` or `VISUAL` is set, `migrate.ts` opens automatically when the command runs in an interactive terminal outside CI without JSON output. `tailordb migration script` opens the file it scaffolds the same way.
 
 3. **Edit `migrate.ts`** to populate data for the new required field:
 
@@ -462,6 +462,25 @@ tailor deploy --migration-skip-steps main-db/backfillUser,main-db/backfillInvoic
 
 Write every step so that running it again is safe: besides the cases above, a step can run a second time when a deploy is interrupted right after it commits. Use `where` clauses that skip rows a step already migrated, as in the example. Rows written while a migration is in progress are not seen by steps that already completed. [Maintenance mode](#maintenance-mode) blocks GraphQL writes but not the writes your resolvers, executors, or workflows make through Kysely, and without it GraphQL clients can write too, so stop such writers until the migration finishes or write steps that tolerate them.
 
+#### Rolling back instead of resuming
+
+By default a failure after another step has completed leaves the migration in progress and the namespace's tables in maintenance mode until you fix the step and deploy again. When you would rather restore the tables first and fix the script afterwards, export `onFailure` next to `steps`:
+
+```typescript
+export const onFailure = "rollback";
+
+export const steps = {
+  // ...
+} satisfies MigrationSteps;
+```
+
+- `onFailure` is `"resume"` (the default, described above) or `"rollback"`. Write it as `export const onFailure = "rollback"` with one of those two string literals; `tailor tailordb migration validate` and `tailor deploy` reject anything else. A script that runs `main` ignores it.
+- With `"rollback"`, a failed step after another step has completed, and post-migration schema changes that fail after every step completed, roll back the pre-migration schema changes like a failing `main` script: tables that already existed are restored to their previous shape and GraphQL permissions, and tables the migration newly introduced are dropped. The in-progress record is cleared before the schema is rolled back, the tables leave maintenance mode, and the checkpoint is not advanced. `tailor deploy` then fails with the step's error under the code `MIGRATION_ROLLED_BACK`, and its suggestion says the next deploy runs every step again. A migration that an earlier deploy left in progress is rolled back the same way once its script exports `"rollback"`, including the tables and GraphQL permissions its earlier Pre-phase wrote.
+- Steps that already completed stay committed. Their changes to existing fields remain in the database, and nothing is recorded as in progress, so the next deploy runs every step again from the beginning. Every step must be safe to run again, or a rolled-back run applies those changes twice. Do not rely on data a step wrote to a field or table that the rollback removed.
+- If `tailor deploy` cannot tell whether a step ran, or the migration's workflow execution may still be running (for example the connection to it was lost), it does not roll anything back even with `"rollback"`: the migration stays in progress as described for a `main` script below. A migration an earlier deploy left in progress is rolled back only when its earlier run is confirmed to have ended, so a failure before that run is inspected, such as a schema error while applying the Pre-phase, keeps it in progress.
+- If the in-progress record cannot be cleared, `tailor deploy` does not roll the schema back. It logs a warning and keeps the migration in progress with its tables in maintenance mode, because a record that outlives a rollback would make the next deploy resume against a schema its completed steps no longer match. Deploy again to resume it as described above, or roll it back without deploying with `tailor tailordb migration resolve --rollback`.
+- If the schema or GraphQL permission of some tables cannot be rolled back, `tailor deploy` still fails with the step's original error. It also warns `Migration <namespace>/<N> was not rolled back completely` and lists the tables that need manual repair, and separately the tables whose GraphQL permission could not be set back. Check them in the workspace and repair them by hand; deploying again does not release them.
+
 ### Settling a migration that stays in progress
 
 When you do not want to resume the migration with another deploy — you abandoned it, or you repaired the data by hand — settle it with `tailor tailordb migration resolve`. Pass exactly one of two options:
@@ -896,7 +915,7 @@ When your branch and main each generated the same number, merging or rebasing st
 
 - 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 validate` in CI to catch uncommitted migrations, broken migration files, unreviewed generated normalization logic, and remote schema drift before deploying. It exits with a non-zero code when validation fails and supports `--json`. Add `--strict` to also require an explicit acknowledgment (a `migrate.ts` or a recorded `--no-script` reason) for every pending migration that can drop data, so destructive changes cannot merge unnoticed.
-- `tailor tailordb migration status` validates file-format compatibility across the full local history, compares its history ID with the deployed namespace, and shows applied and pending migrations for a human-readable comparison. Its exit code is non-zero on incompatible files, migration history mismatches, and remote read errors, so check the output.
+- `tailor tailordb migration status` validates the layout and file-format compatibility of the full local history, compares its history ID with the deployed namespace, and shows applied and pending migrations for a human-readable comparison. Its exit code is non-zero on invalid or incompatible files, migration history mismatches, and remote read 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
@@ -905,10 +924,10 @@ Use `tailor tailordb migration rebaseline` rather than combining `migration gene
 
 ## Failure Recovery
 
-A script that exports `steps` follows different rules once one of its steps has completed: the migration stays in progress and the next deploy resumes it. See [Splitting a migration into steps](#splitting-a-migration-into-steps). Otherwise, if the pre-migration phase or `migrate.ts` fails:
+A script that exports `steps` follows different rules once one of its steps has completed: the migration stays in progress and the next deploy resumes it, unless the script exports `onFailure = "rollback"`. See [Splitting a migration into steps](#splitting-a-migration-into-steps) and [Rolling back instead of resuming](#rolling-back-instead-of-resuming). Otherwise, if the pre-migration phase or `migrate.ts` fails:
 
 - **The transaction rolls back** for that migration's script. Database changes the script made are undone.
-- **The pre-migration schema changes are rolled back** to the prior checkpoint: tables that already existed are restored to their previous shape, and tables the migration newly introduced are dropped. The workspace is left at its prior checkpoint and prior schema — not half-applied.
+- **The pre-migration schema changes are rolled back** to the prior checkpoint: tables that already existed are restored to their previous shape and GraphQL permissions, and tables the migration newly introduced are dropped. The workspace is left at its prior checkpoint and prior schema — not half-applied.
 - The whole `apply` aborts and the checkpoint label is not bumped. Subsequent migrations in the same run do not execute.
 
 The rollback is best-effort per table; if reverting a table fails, a warning is logged and the original migration error is still reported. The next deploy then stops with remote schema drift on that table. Run `tailor tailordb migration validate` to see which tables differ, return the namespace to its checkpoint with `tailor tailordb migration sync <N>`, where `<N>` is the checkpoint `tailor tailordb migration status` reports, and deploy again. `sync` deletes the tables and fields that are not in that migration's snapshot, together with any rows the failed migration wrote to them; the next deploy runs the failed migration again.
@@ -1037,10 +1056,12 @@ npm install -D @electric-sql/pglite
 
 The generated `db.pglite.ts` exports the `CREATE TABLE` script for the same schema `db.ts` types — the tables as the pre-migration phase leaves them while `migrate.ts` runs, including relaxed constraints, renamed fields under both names, and retained removed fields. Run it once on the PGlite instance, stage rows, then run the script in a transaction. `tailor tailordb migration script <N> --with-test` scaffolds this test too when `@electric-sql/pglite` is installed. Type the instance with `Unmigrated<Database>` rather than `Database`: `db.ts` types a column the migration makes required as `T | null` on read but `T` on write (and an enum it narrows as the old values on read but the new ones on write), so that `migrate.ts` cannot write what the migration is removing — which would also stop the test from staging the rows the script has to convert. `Unmigrated` lets every column be written with whatever it can still be read as; `main` still receives a `Transaction<Database>`.
 
+Relations are enforced as on the platform: a row that points at a parent that does not exist is rejected. Write the records the test starts from inside `prepareFixtures`, which leaves relations unchecked while it runs, so you can stage rows that predate a relation, such as rows whose parent does not exist that the script repairs. Relations are checked again when it returns, so the script itself still cannot write a missing parent. NOT NULL, UNIQUE, and CHECK constraints stay enforced. A relation is left unenforced while the pre-migration schema cannot satisfy it: when a pending type change leaves the field a different type from its target, when the migration retargets the relation to another table, or when the target field's unique constraint is still withheld. How relations on array fields and inside nested objects behave is described under [Real SQL execution with PGlite](../../testing.md#real-sql-execution-with-pglite-mocktailordbwithpglite).
+
 ```typescript
 // migrations/0005/migrate.pglite.test.ts
 import { PGlite } from "@electric-sql/pglite";
-import { createKyselyPGlite, type Unmigrated } from "@tailor-platform/sdk/vitest";
+import { createKyselyPGlite, prepareFixtures, type Unmigrated } from "@tailor-platform/sdk/vitest";
 import { afterAll, beforeAll, describe, expect, test } from "vitest";
 import { pgliteSchema } from "./db.pglite";
 import { main } from "./migrate";
@@ -1061,13 +1082,15 @@ afterAll(async () => {
 describe("0005 add required email", () => {
   test("backfills null emails and keeps existing ones", async () => {
     const now = new Date();
-    await db
-      .insertInto("User")
-      .values([
-        { name: "a", email: null, createdAt: now, updatedAt: now },
-        { name: "b", email: "b@example.com", createdAt: now, updatedAt: now },
-      ])
-      .execute();
+    await prepareFixtures(pglite, async () => {
+      await db
+        .insertInto("User")
+        .values([
+          { name: "a", email: null, createdAt: now, updatedAt: now },
+          { name: "b", email: "b@example.com", createdAt: now, updatedAt: now },
+        ])
+        .execute();
+    });
 
     await db.transaction().execute((trx) => main(trx));
 

package/docs/testing.md

@@ -209,12 +209,12 @@ test("upserts against real rows", async () => {
 });
 ```
 
-The generated columns follow the Kysely types, not TailorDB's storage: `text` for string and enum fields, `timestamptz` for datetime, `date` and `time` for date and time, `numeric` for decimal, rounded to the configured scale and read back with exactly that many fractional digits, `jsonb` for nested objects (and arrays of them), Postgres arrays for other array fields. `id` is a generated `uuid` primary key, `.unique()` fields and unique `.indexes()` are enforced, so `ON CONFLICT` upserts behave, and `.default()` values become column defaults (`"now"` becomes the current time). `.serial()` fields are assigned by the database from the configured `start`, `maxValue`, and format. Relations are enforced as the platform does: a row that points at a parent that does not exist is rejected with an error containing `violates foreign key constraint`, so create parent rows before their children. This includes relations on array fields. A relation declared on a field inside a nested object is not enforced, as on the platform.
+The generated columns follow the Kysely types, not TailorDB's storage: `text` for string and enum fields, `timestamptz` for datetime, `date` and `time` for date and time, `numeric` for decimal, rounded to the configured scale and read back with exactly that many fractional digits, `jsonb` for nested objects (and arrays of them), Postgres arrays for other array fields. `id` is a generated `uuid` primary key, `.unique()` fields and unique `.indexes()` are enforced, so `ON CONFLICT` upserts behave, and `.default()` values become column defaults (`"now"` becomes the current time). `.serial()` fields are assigned by the database from the configured `start`, `maxValue`, and format. Relations are enforced as the platform does: a row that points at a parent that does not exist is rejected with an error containing `violates foreign key constraint`, so create parent rows before their children. This includes relations on array fields and on fields inside nested objects.
 
 What the script cannot reproduce:
 
 - Hooks, validations, and permissions do not run. A required field whose value only its own field-level create hook supplies is created nullable, so inserts that omit it succeed; give it a `.default()` if the test reads it back. A field filled by a table-level hook stays `NOT NULL`, as its Kysely type still requires it on insert.
-- Relations on array fields, and relations from a field whose type differs from the field it points at (such as a `string` field related to `id`), are checked only when a row is written. Deleting a parent that such a row still points at is rejected by the platform but not by PGlite, and changing the parent's `id` is not checked either, so a test must not expect PGlite to reject them.
+- Relations on array fields and on fields inside nested objects, and relations from a field whose type differs from the field it points at (such as a `string` field related to `id`), are checked only when a row is written. Deleting a parent that such a row still points at is rejected by the platform but not by PGlite, and changing the parent's `id` is not checked either, so a test must not expect PGlite to reject them.
 - Serial formats are reproduced for a single `%d`, `%x`, or `%X` specifier with an optional zero-padded width; an octal `%o` format fails generation with an error naming the field.
 - `gapless` is not reproduced: the numbers come from a sequence, so an insert that fails still uses up its number.
 - A date or datetime inside a nested object reads back as a string from `jsonb`, not a `Date`, or a `Temporal.PlainDate` or `Temporal.Instant` under `kyselyTypePlugin({ temporal: true })`, although the platform returns those types.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.32.0",
+  "version": "2.34.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -160,25 +160,25 @@
     "@bufbuild/protovalidate": "1.3.0",
     "@connectrpc/connect": "2.2.0",
     "@connectrpc/connect-node": "2.2.0",
-    "@inquirer/core": "12.0.4",
-    "@inquirer/prompts": "8.7.3",
+    "@inquirer/core": "12.0.5",
+    "@inquirer/prompts": "8.7.4",
     "@jridgewell/trace-mapping": "0.3.31",
-    "@napi-rs/keyring": "2.1.1",
+    "@napi-rs/keyring": "2.1.2",
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/context-async-hooks": "2.12.0",
     "@opentelemetry/exporter-trace-otlp-proto": "0.223.0",
     "@opentelemetry/resources": "2.12.0",
     "@opentelemetry/sdk-trace": "2.12.0",
     "@opentelemetry/semantic-conventions": "1.43.0",
-    "@oxc-project/types": "0.154.0",
-    "@politty/zod": "0.5.2",
+    "@oxc-project/types": "0.155.0",
+    "@politty/zod": "0.6.1",
     "@secretlint/core": "13.0.7",
     "@secretlint/secretlint-rule-preset-recommend": "13.0.7",
     "@standard-schema/spec": "1.1.0",
     "@tailor-platform/function-kysely-tailordb": "0.1.3",
     "@toiroakr/read-multiline": "0.4.3",
     "@urql/core": "6.0.3",
-    "amaro": "1.2.1",
+    "amaro": "1.2.2",
     "confbox": "0.3.1",
     "date-fns": "4.4.0",
     "es-toolkit": "1.52.0",
@@ -192,12 +192,12 @@
     "lines-db": "0.18.0",
     "mime-types": "3.0.2",
     "open": "11.0.4",
-    "oxc-parser": "0.154.0",
+    "oxc-parser": "0.155.0",
     "p-limit": "7.3.3",
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
-    "pkg-types": "2.3.3",
-    "rolldown": "1.2.14",
+    "pkg-types": "2.4.0",
+    "rolldown": "1.2.15",
     "semver": "7.8.5",
     "sql-highlight": "6.1.0",
     "std-env": "4.3.0",
@@ -209,18 +209,18 @@
     "zod": "4.6.7"
   },
   "devDependencies": {
-    "@ark/attest": "0.57.0",
-    "@electric-sql/pglite": "0.5.10",
+    "@ark/attest": "0.58.0",
+    "@electric-sql/pglite": "0.5.11",
     "@tailor-platform/shared": "^0.0.0",
     "@tailor-platform/tailor-proto": "^0.0.1",
     "@types/mime-types": "3.0.1",
     "@types/node": "24.19.2",
     "@types/semver": "7.8.0",
     "@vitest/coverage-v8": "5.0.5",
-    "eslint-plugin-zod": "5.2.0",
-    "oxfmt": "0.73.0",
-    "oxlint": "1.88.0",
-    "oxlint-tsgolint": "7.0.2004",
+    "eslint-plugin-zod": "5.2.1",
+    "oxfmt": "0.74.0",
+    "oxlint": "1.89.0",
+    "oxlint-tsgolint": "7.0.2005",
     "sonda": "0.14.0",
     "tsdown": "0.23.1",
     "tsrs": "0.16.0-ts7.1.0-dev.20260929",

package/dist/application-C2bPmmbh.mjs

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