@tailor-platform/sdk 2.35.0 → 2.37.0

package/CHANGELOG.md

@@ -1,5 +1,113 @@
 # @tailor-platform/sdk
 
+## 2.37.0
+
+### Minor Changes
+
+- [#2899](https://github.com/tailor-platform/sdk/pull/2899) [`610a5f4`](https://github.com/tailor-platform/sdk/commit/610a5f4dbb265f83ddbcd82c86426c457aa03e9b) Thanks [@dqn](https://github.com/dqn)! - Log views now tell lines the Platform added to an execution's logs apart from your function's own output. `function logs`, `workflow executions --logs` (and `workflow start/wait/resume --logs`), and `executor jobs/trigger --wait --logs` mark those lines with `[PLATFORM]`, and each log entry in `--json` output carries `source` (`USER`, `PLATFORM`, or `UNSPECIFIED`); executor job results also gain `functionLogEntries` and `workflowJobLogs[].logEntries`. `function logs` adds `hasPlatformLogs` to each execution, a best-effort flag where `false` does not guarantee there are none, and shows it as a column in the list table when any listed execution is flagged.
+
+- [#2889](https://github.com/tailor-platform/sdk/pull/2889) [`dbbd42c`](https://github.com/tailor-platform/sdk/commit/dbbd42c3eb58da25c83d46872dcc756e0a61be0c) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: `tailor deploy` and `tailor tailordb migration validate` now check a deployed TailorDB namespace that has no migration checkpoint yet against migration `0000`, as `tailor tailordb migration test` already did. Previously they skipped the check, so the first deploy after adding migrations to an existing project overwrote tables that differed from `0000`, for example deleting a field added in the console. When the tables differ, `tailor deploy` stops with `MIGRATION_REMOTE_DRIFT` and `migration validate` fails, and both suggest the two ways to reconcile them before the first deploy with migrations: overwrite the deployed tables with `tailor tailordb migration sync 0000`, or update the local tables to match the deployed ones and recreate `0000` with `tailor tailordb migration generate --init`. A deploy that stopped after creating only some of the tables also needs `migration sync 0000`. `migration validate --json` no longer reports `skipped: "no_migration_label"`: a namespace with tables but no checkpoint reports `checkpointUnset: true`, and one without tables reports `skipped: "not_deployed"`, which `migration test` now refuses as not deployed.
+
+- [#2891](https://github.com/tailor-platform/sdk/pull/2891) [`f14929d`](https://github.com/tailor-platform/sdk/commit/f14929d46243e5e55fd7348666ec54189881e882) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: Declining the breaking-change confirmation for a namespace in `tailor tailordb migration generate` is no longer a failure. The command skips that namespace, still writes the others, exits 0, and ends with a `Skipped: <namespaces>` line. The JSON result gains a matching `skippedNamespaces` field, which stays empty because JSON output never prompts. Declining the `--init` confirmation still fails with `MIGRATION_GENERATE_CANCELLED`. `migrateGenerate()` now returns `Promise<MigrateGenerateResult>` instead of `Promise<void>` and resolves instead of rejecting when breaking changes are declined. Update explicit return-type annotations and check `result.skippedNamespaces` before continuing if your script must stop after a decline.
+
+- [#2893](https://github.com/tailor-platform/sdk/pull/2893) [`15f1158`](https://github.com/tailor-platform/sdk/commit/15f1158edbc304c5c899527119b3cfcfa74ab1b1) Thanks [@dqn](https://github.com/dqn)! - With `--json`, `tailor workspace create --ttl` now reports how recording the expiry went: `ttl.state` is `written` with `expiresAt`, or `unconfirmed` with `requestedExpiresAt` when the command fails with `WORKSPACE_TTL_WRITE_FAILED` after creating the workspace. A script can read the workspace ID from that output and record the expiry again with `tailor workspace ttl set`. Both the command and `createWorkspace({ ttl })` now try the expiry write a second time before reporting it unconfirmed. The expiry that `tailor workspace create`, `createWorkspace({ ttl })`, and `tailor workspace ttl set` report is now the instant the workspace records, at one-second resolution, matching `tailor workspace get`.
+  
+  `tailor workspace create --ttl`, `createWorkspace({ ttl })`, `tailor workspace ttl set`, and `tailor tailordb migration test --keep-ttl` now reject a TTL of 50,000,000 days or more before contacting the Platform. Previously a TTL past the supported date range made `tailor workspace create` fail with an unexpected error after creating the workspace.
+
+- [#2896](https://github.com/tailor-platform/sdk/pull/2896) [`7d83a4a`](https://github.com/tailor-platform/sdk/commit/7d83a4aab244aeb16f1c0d873fd869b4a6ed07da) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: `tailor tailordb migration set` now refuses the number of a migration that an earlier deploy left in progress, as it already refused every other number. Previously it moved the checkpoint to that migration and cleared its in-progress record without applying the migration's schema, taking its tables out of maintenance mode, or removing the temporary resources of the failed run, so the next deploy stopped with `MIGRATION_REMOTE_DRIFT`. Settle such a migration with `tailor tailordb migration resolve --complete`, which does all of these, or return to the migration before it with `tailor tailordb migration resolve --rollback`; a migration whose steps partly committed can also be resumed with `tailor deploy`.
+  
+  `tailor tailordb migration status` now lists those commands under a migration in progress, keeping the `--config`, `--workspace-id`, and `--profile` it ran with, and `--json` reports them as `inProgressMigrationActions`, each with the `command` and `args` to run. The `MIGRATION_IN_PROGRESS` error of `set`, `sync`, `rebaseline`, and `migration test` suggests the same commands.
+
+- [#2885](https://github.com/tailor-platform/sdk/pull/2885) [`6ecf16b`](https://github.com/tailor-platform/sdk/commit/6ecf16b4e460143491e1054e092fa9269ddb7b34) Thanks [@toiroakr](https://github.com/toiroakr)! - **Breaking change (beta)**: Removed the `executable` option from the files a plugin returns in `GeneratorResult.files`. `tailor generate` no longer runs `chmod 755` on a generated file, so a file it creates gets the default permissions. `executable: true` is a type error only where the hook's return type is annotated (`: GeneratorResult`) or the file is pushed into a `GeneratorResult["files"]` array; a hook without an annotation, or one that builds its files through a variable or `.map`, compiles and the flag is silently ignored, so search your plugins for `executable` when you upgrade. A file that an earlier version made executable keeps that mode when it is regenerated, so run `chmod -x` on it once. To run a generated script, call it through its interpreter (`node generated/cli.mjs`, `sh generated/run.sh`), call it from a `package.json` script, or add a `chmod +x` step after `tailor generate`.
+
+- [#2863](https://github.com/tailor-platform/sdk/pull/2863) [`a046821`](https://github.com/tailor-platform/sdk/commit/a0468215296be0c96001cf792e9b0d121c176243) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: `tailor deploy --no-schema-check` now stops with `MIGRATION_CHECKPOINT_UNKNOWN` when a namespace's remote migration checkpoint is not in the local migration history, as `tailor deploy` without the option already did. Previously it moved the checkpoint back to the latest local migration and overwrote the tables with the local schema, for example when run from an outdated checkout. The option now skips only the local and remote schema checks. Pull the latest migration files, or move the checkpoint on purpose with `tailor tailordb migration sync <N>` or `tailor tailordb migration set <N>`, adding `--force` when the namespace records another migration history ID or one that cannot be read, then deploy again. With or without the option, the error now suggests both commands, with `--force` where it is needed, for each namespace whose checkpoint can move to a local migration, and reports each namespace's remote checkpoint, latest local migration, and whether it records another migration history ID or one that cannot be read in `context` under `--json`.
+  
+  `migration validate` and `migration status` now also explain how to recover a checkpoint outside the local history with `sync` or `set`, including `--force` where it is needed. The `migration validate --json` report gives `localLatestMigration` and `historyIdMismatch` for such a checkpoint.
+
+- [#2892](https://github.com/tailor-platform/sdk/pull/2892) [`f399327`](https://github.com/tailor-platform/sdk/commit/f3993270738ca54a7ee14b8f3fab336f8770f946) Thanks [@dqn](https://github.com/dqn)! - Add recovery suggestions to deploy and TailorDB migration failures that had none. `DEPLOY_LOCK_TIMEOUT` names the lock directory to delete when no deploy is running; `tailordb migration rebaseline` refusals over another migration history or a drifted schema suggest `migration set --force` or `migration sync`; a failed post-checkpoint cleanup suggests `migration sync`; `MIGRATION_FILES_INVALID` suggests restoring the files or `migration generate --init`; `tailordb migration test` suggests pulling the latest migrations when the source checkpoint is outside the local history, or names `migration validate` and `migration status` when the source schema has drifted from its checkpoint; `deploy` with an unknown workspace ID points at `tailor workspace list`; and prompts that cannot be shown name the option or environment variable to pass instead. An unknown profile now fails with `PROFILE_NOT_FOUND` instead of `UNEXPECTED_ERROR` under `--json`, and suggests `tailor profile list`. `prompt.confirm`, `prompt.text`, `prompt.password`, and `prompt.select` from `@tailor-platform/sdk/cli` accept `suggestion`, reported when the prompt cannot be shown.
+
+- [#2864](https://github.com/tailor-platform/sdk/pull/2864) [`1c37375`](https://github.com/tailor-platform/sdk/commit/1c37375e4ed46b03c4418536643279cb04a4b293) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: `tailor tailordb migration set` and `tailor tailordb migration sync` now refuse to run when the namespace records a migration history ID that does not match the local migration history, or one that cannot be read, instead of overwriting it after confirmation. A namespace with neither a checkpoint nor a history ID yet is still accepted. To write the local history over another one on purpose, pass the new `--force` option; the command names the history ID it replaces and still asks for confirmation unless `--yes` is given.
+
+### Patch Changes
+
+- [#2866](https://github.com/tailor-platform/sdk/pull/2866) [`a2deb70`](https://github.com/tailor-platform/sdk/commit/a2deb70140fb8a77e7dffa9a97322e1c184114df) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now checks, while planning and so also with `--dry-run`, that each pending migration script can run: auth is configured, a machine user is available and defined in `auth.machineUsers`, and the script can be bundled. Previously these failures surfaced only after prerequisite resources were applied, and a missing machine user only after tables entered maintenance mode. A `migration.machineUser` not defined in `auth.machineUsers` is now rejected with `MACHINE_USER_NOT_FOUND` before the deploy instead of failing when the script starts, and a bundle failure that had no error code now reports `MIGRATION_SCRIPT_BUNDLE_FAILED` with the namespace and migration number. `tailor tailordb migration test --machine-user` now also runs the pending migration scripts as that machine user.
+
+- [#2878](https://github.com/tailor-platform/sdk/pull/2878) [`fe47a5c`](https://github.com/tailor-platform/sdk/commit/fe47a5c45685ddbbca002a938e362fd923e53522) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now reads its config paths from `TAILOR_CONFIG_PATH`, as the other commands do. It accepts comma-separated paths there, and `--env-file` can set it. `TAILOR_PLATFORM_SDK_CONFIG_PATH` still works when `TAILOR_CONFIG_PATH` is not set, with a deprecation warning; rename it to `TAILOR_CONFIG_PATH`.
+
+- [#2894](https://github.com/tailor-platform/sdk/pull/2894) [`097dd02`](https://github.com/tailor-platform/sdk/commit/097dd02de6ff4e056abaf8f08a3de74eb56a764c) Thanks [@dqn](https://github.com/dqn)! - The recovery commands that `tailor deploy` and the `tailor tailordb migration` commands suggest for a migration now target the workspace the run used. A suggested `tailor tailordb migration status`, `sync`, `set`, or `resolve` command keeps the run's `--config`, `--workspace-id`, and `--profile`, and for `deploy` also its `--env-file` or `--env-file-if-exists`; a suggested `tailor workflow executions` command keeps the same options except `--config`. Previously these suggestions dropped them, so running one as shown could target the workspace of the shell environment instead, and `sync` could rewrite the tables there.
+
+- [#2854](https://github.com/tailor-platform/sdk/pull/2854) [`3519c27`](https://github.com/tailor-platform/sdk/commit/3519c270211b3fad18729c4f96a460abbffe68ea) Thanks [@dqn](https://github.com/dqn)! - The SDK now rejects a relation whose field type differs from the type of the field it points at, such as a `db.string()` field related to `id`, and a `toward.key` that the target table does not have or that is not unique. A `db.string()` field related to `id` deployed, but `tailor query --engine sql` failed with `internal error` when inserting a non-null value into it and when deleting any row of the referenced table. Through GraphQL, a non-UUID value failed with `unknown error`, and a child holding an uppercase UUID did not stop its parent's deletion. To fix such a relation, remove its `.relation()`, or change the field to the type of the field it points at (`db.uuid()` for `id`) and convert its stored values as "Converting a field type" in the TailorDB migration docs describes.
+
+- [#2849](https://github.com/tailor-platform/sdk/pull/2849) [`733e71d`](https://github.com/tailor-platform/sdk/commit/733e71d1978e7ab6294c366eafb426fdf18eb243) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` no longer starts a migration's script when the namespace's checkpoint or migration history changed after the deploy read it, for example through `tailor tailordb migration set` or another deploy. It fails with `MIGRATION_CHECKPOINT_CONFLICT` before recording the migration as in progress, instead of recording it on top of the changed checkpoint, which left every later deploy and `tailor tailordb migration resolve` refusing the namespace. When it cannot read them at that point, it fails with `MIGRATION_CHECKPOINT_UNVERIFIED` without starting the script. A deploy whose first migration of a namespace fails before its checkpoint now also returns the tables to their previous settings when the namespace had no checkpoint yet or, with `--no-schema-check`, records another migration history; it used to report the checkpoint as changed concurrently and leave the tables in maintenance mode.
+
+- [#2852](https://github.com/tailor-platform/sdk/pull/2852) [`546842c`](https://github.com/tailor-platform/sdk/commit/546842cead188f571b0d38944bfaf517078f9436) Thanks [@dqn](https://github.com/dqn)! - IdP client names in `defineIdp()` `clients` and in a built-in IdP `idProvider` must now be 3 to 63 lowercase letters, digits, or hyphens, starting and ending with a letter or digit, and the config fails to load otherwise. Before, a client with a name such as `c1` was created, but the platform refuses to read or delete it, so removing the client or its IdP failed every `deploy` and `remove`, and an Auth service that used it as its built-in IdP failed to deploy. Rename such a client in `clients` and `idp.provider()`: `deploy` then warns that the old client and its secret vault stay in the workspace instead of failing to delete them. Removing the whole IdP now deletes such a client and its secret vault along with it.
+
+- [#2898](https://github.com/tailor-platform/sdk/pull/2898) [`6ec81e9`](https://github.com/tailor-platform/sdk/commit/6ec81e9bb53cc607f884c6fcde005e670d9aa18d) Thanks [@dqn](https://github.com/dqn)! - `tailor api` can inspect and call the notification endpoints (`ListMyNotifications`, `GetMyNotification`, `CountMyUnreadNotifications`, `MarkMyNotificationsRead`, `DismissMyNotification`).
+
+- [#2856](https://github.com/tailor-platform/sdk/pull/2856) [`38a9d9e`](https://github.com/tailor-platform/sdk/commit/38a9d9e8271f833a5ee5b83a2ee851d8bf2217f9) Thanks [@dqn](https://github.com/dqn)! - OAuth2 client names in `defineAuth()` `oauth2Clients` must now be 3 to 63 lowercase letters, digits, or hyphens, starting and ending with a letter or digit, and the config fails to load otherwise. The platform already rejects such a name, so `deploy` used to fail partway, after creating other resources; rename the client to deploy or remove the application. A config key that breaks a naming rule, such as an OAuth2 client name, is now reported with that rule instead of `Invalid key in record`.
+
+- [#2789](https://github.com/tailor-platform/sdk/pull/2789) [`bdc26af`](https://github.com/tailor-platform/sdk/commit/bdc26afa7dc738914869e23ba7ed422e7e6692bd) Thanks [@toiroakr](https://github.com/toiroakr)! - A relation on a field inside `db.object()` that points at its own table, such as `links.parentID` on `Node`, now works with `tailor seed apply` and with the data copy of a table rename. Seed rows are inserted parent first, including when the reference sits inside a nested array, and a rename copy inserts the reference as null and restores it once every row exists. The rename copy now restores the references with one update per row instead of a single update with a subselect, which the platform rejects; this also fixes the copy of a table that has a self-reference on a top-level field. A table whose self-referential foreign key inside a nested field is required is no longer detected as a rename, because the copy cannot insert such a row before its parent. A table with a self-referential foreign key that points at another column which is itself a self-referential foreign key is not detected as a rename either, because restoring the references row by row could point at a key that is not back yet, and neither is a table whose nested field holding a self-referential foreign key is covered by a unique constraint, because clearing the references makes distinct values equal.
+
+- [#2848](https://github.com/tailor-platform/sdk/pull/2848) [`48f31c5`](https://github.com/tailor-platform/sdk/commit/48f31c592f3a3688d2b9b1901b2ff0c9f093fbf2) Thanks [@dqn](https://github.com/dqn)! - Editor tooltips and `--help` now flag beta APIs. `**Beta:**` appears in the JSDoc of every `@tailor-platform/sdk/vitest` and `@tailor-platform/sdk/plugin` export, `definePlugins`, the plugin authoring types, `.plugin()` and `plugins` on tables, `maintenanceMode`, the TailorDB `migration` config, and the migration exports and `noSchemaCheck` / `migrationSkipSteps` deploy options of `@tailor-platform/sdk/cli`. `(beta)` appears in the descriptions of `tailordb migration`, `deploy --no-schema-check`, and `deploy --migration-skip-steps`.
+
+- [#2878](https://github.com/tailor-platform/sdk/pull/2878) [`b286e5e`](https://github.com/tailor-platform/sdk/commit/b286e5e0c8cda829185870b00bfccb8623ba9a13) Thanks [@dqn](https://github.com/dqn)! - `PLATFORM_URL` and `PLATFORM_OAUTH2_CLIENT_ID`, which v2 renamed to `TAILOR_PLATFORM_URL` and `TAILOR_PLATFORM_OAUTH2_CLIENT_ID`, still work when the new names are not set, but now print a deprecation warning once per run; rename them to the new names. An empty value of any of these variables now counts as unset.
+
+- [#2846](https://github.com/tailor-platform/sdk/pull/2846) [`535ba8d`](https://github.com/tailor-platform/sdk/commit/535ba8d1c259d6f75726a4da47ff02a8b80a5446) Thanks [@renovate](https://github.com/apps/renovate)! - chore(deps): update dependency node to v26
+
+- [#2859](https://github.com/tailor-platform/sdk/pull/2859) [`d910afd`](https://github.com/tailor-platform/sdk/commit/d910afddc92da9dfa5b04380cefb75203a657e66) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update secretlint monorepo to v13.1.0
+
+- [#2872](https://github.com/tailor-platform/sdk/pull/2872) [`aecd163`](https://github.com/tailor-platform/sdk/commit/aecd1636101abfa8cb8b267259d8ecc0938feaea) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency lines-db to v0.18.1
+
+- [#2875](https://github.com/tailor-platform/sdk/pull/2875) [`1883f3b`](https://github.com/tailor-platform/sdk/commit/1883f3b20ba368481838b521de04ffc8334d03d4) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update @​inquirer
+
+- [#2877](https://github.com/tailor-platform/sdk/pull/2877) [`22af4a5`](https://github.com/tailor-platform/sdk/commit/22af4a556df7171b61af67f50edbcf35248b9dff) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update oxc to v0.156.0
+
+- [#2879](https://github.com/tailor-platform/sdk/pull/2879) [`c726029`](https://github.com/tailor-platform/sdk/commit/c72602926d25b9267c35c1b5bd97c7a03531724b) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now prints the plan before asking to confirm deletions, owner conflicts, unmanaged resources, missing dependent applications, or migration checkpoint resets, so you answer each confirmation with the whole plan in view. When `env` references the URL of a static website the same deploy creates, `deploy` prints the plan it makes again with the real URL and asks only about what that plan adds.
+
+- [#2888](https://github.com/tailor-platform/sdk/pull/2888) [`e990dbd`](https://github.com/tailor-platform/sdk/commit/e990dbd4093ffba57717f7b897f3cd2d8e2cdc12) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now suggests `--force` when a migration's checkpoint changes during the deploy to a migration history other than the local one, or to one whose label cannot be read. `MIGRATION_CHECKPOINT_CONFLICT` used to suggest `tailor tailordb migration sync <N>` without `--force`, which `sync` refuses for such a namespace. It now suggests `sync <N> --force` only for when the local migration history should replace the deployed one, and otherwise suggests working from a checkout of the deployed history. The error names a different migration history only when the namespace records one other than the local history, and its `context` adds `localHistoryId`, `remoteHistoryIdInvalid`, and `historyIdMismatch`. The recovery hints that `tailor deploy`, `tailor tailordb migration status`, and `migration validate` print for a checkpoint outside the local history also suggest a checkout of the deployed history before their `--force` commands.
+
+- [#2884](https://github.com/tailor-platform/sdk/pull/2884) [`e06d59b`](https://github.com/tailor-platform/sdk/commit/e06d59ba55a28ab0643fbdf234fdb0d95082634f) Thanks [@dqn](https://github.com/dqn)! - Add `tailor setup ci autofix`, which generates `.github/workflows/tailor-autofix.yml`: on every pull request it runs `tailor generate` and commits what that changes to the pull request branch, so a pull request whose generated files are out of date no longer needs a local `tailor generate` and a new commit. `--provider` chooses what makes the commit: `github-token` (the default, with the workflow token; GitHub then waits for someone with write access to approve the workflows of the fix commit), `github-app` (a GitHub App token, so the checks run right away), `autofix-ci`, or `securefix`. Fork and Dependabot pull requests are skipped, except with `autofix-ci`. `tailor setup update`, `check`, and `delete` handle the new workflow, and `tailor setup ci env` lists and checks the repository secret and variable that `github-app` and `securefix` need. With `--json`, `tailor setup ci env` then reports them as an entry whose `environment` is `null`.
+  
+  This release also raises the workflow template version, so `tailor setup check` reports a template-version finding for existing workflows until you run `tailor setup update`. With `TAILOR_PLATFORM_FAIL_ON_DRIFT` set to `true`, the drift check fails until then.
+
+- [#2855](https://github.com/tailor-platform/sdk/pull/2855) [`cab7fb8`](https://github.com/tailor-platform/sdk/commit/cab7fb8417e8d451ced34203a4add976ff0a8690) Thanks [@dqn](https://github.com/dqn)! - Fix workflow jobs exported under names such as `main`, `env`, or `invoker` failing to bundle or run in `tailor deploy` and `tailor function run`
+
+## 2.36.0
+
+### Minor Changes
+
+- [#2829](https://github.com/tailor-platform/sdk/pull/2829) [`6cbf20b`](https://github.com/tailor-platform/sdk/commit/6cbf20b798a5303a21fd99c6b7726bb342ad8d4b) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: A query issued on a `createKyselyPGlite` instance while one of its transactions is open now waits for the transaction to finish. Before, the query ran inside the transaction, and when it failed, the commit silently discarded the transaction's writes. A query on the outer instance from inside the transaction now never finishes and the test times out; run it on `trx` instead.
+
+- [#2847](https://github.com/tailor-platform/sdk/pull/2847) [`55e9a94`](https://github.com/tailor-platform/sdk/commit/55e9a94a593406e7790f73b73c3714ba96eda8f7) Thanks [@jackchuka](https://github.com/jackchuka)! - **Breaking change**: `workspace create`, workspace creation during `deploy`, and the programmatic `createWorkspace()` now require an organization. Pass `--organization-id` (or set `TAILOR_PLATFORM_ORGANIZATION_ID`), or set a default organization with `tailor user update --default-organization-id` (not read while `TAILOR_PLATFORM_TOKEN` or `TAILOR_TOKEN` is set). Without one, interactive `deploy` asks which organization to create the workspace in; `workspace create`, `createWorkspace()`, and non-interactive `deploy` fail instead of creating a workspace outside any organization.
+
+### Patch Changes
+
+- [#2833](https://github.com/tailor-platform/sdk/pull/2833) [`e3e3bac`](https://github.com/tailor-platform/sdk/commit/e3e3bac2e1fdc9b695db38d90e25abe7d40923ce) Thanks [@dqn](https://github.com/dqn)! - Adding a relation to an existing field is now a breaking change in `tailor tailordb migration generate`, and the migration needs a script. It was recorded as non-breaking, so values that point at no record stayed stored, and after deploy the platform rejected any later update of those rows, even one that changes another field. The generated `migrate.ts` finds those values and asks for their new reference with `TODO`, or leaves the elements of an array field to a single `TODO`. The foreign key is applied after the script runs, so the script and the other steps of the migration can update those rows. A relation added to a field inside `db.object()` stays non-breaking. The script generated for a relation retargeted to another table now also works when the relation points at its own table or at a key other than `id`.
+
+- [#2831](https://github.com/tailor-platform/sdk/pull/2831) [`2d6217b`](https://github.com/tailor-platform/sdk/commit/2d6217b690bb25c1a825f1c40f8d437bb64d5140) Thanks [@dqn](https://github.com/dqn)! - `.unique()` and `.index()` on a `db.object()` field itself now fail type checking, and `tailor generate` and `tailor deploy` stop with an error naming the field. Before, such a table field failed to deploy with an internal platform error, and such a member of another `db.object()` was deployed without the setting, so in a namespace with `migration.directory` every later deploy stopped with `MIGRATION_REMOTE_DRIFT`. Remove the modifier; for such a member in a namespace with `migration.directory`, then run `tailor tailordb migration generate` and `tailor deploy --no-schema-check` once.
+
+- [#2811](https://github.com/tailor-platform/sdk/pull/2811) [`e229992`](https://github.com/tailor-platform/sdk/commit/e229992b0861fe17f306d2e2405104a9cb2c371c) Thanks [@toiroakr](https://github.com/toiroakr)! - TailorDB namespaces that set the same `migration.directory` now fail with `MIGRATION_DIRECTORY_CONFLICT`, naming the namespaces and the shared directory, before any migration command or `tailor deploy` reads or writes migration files. Before, `migration generate` failed with a misleading "Possible rename(s) detected" error, and `migration generate --init` rebuilt the history of every namespace sharing the directory. Give each namespace its own `migration.directory`.
+
+- [#2828](https://github.com/tailor-platform/sdk/pull/2828) [`eab9a23`](https://github.com/tailor-platform/sdk/commit/eab9a23368da6b084f0ebc73dd90d38fb3665ca7) Thanks [@dqn](https://github.com/dqn)! - Keep existing migration files when `tailordb migration generate --init` fails to load tables. Previously the migrations were deleted before the tables loaded, so an error such as a syntax error in a table file left the namespace with no migration history. The deletion confirmation now appears after the tables load.
+
+- [#2776](https://github.com/tailor-platform/sdk/pull/2776) [`beacc64`](https://github.com/tailor-platform/sdk/commit/beacc643ec0a429736448f9074667106eb09ba1a) Thanks [@toiroakr](https://github.com/toiroakr)! - `tailor tailordb migration status` now reports an error for a namespace whose remote checkpoint is ahead of the latest local migration, for example `0009` on the workspace while the local history ends at `0002`. It used to show that namespace as up to date with no pending migrations. With `maintenanceMode` on, `tailor deploy` also records the maintenance mode with every migration checkpoint of a namespace instead of only the last one, so a deploy that stops after the first of several migrations leaves the record that `tailor tailordb migration resolve` and the next deploy use to lift the maintenance mode.
+
+- [#2835](https://github.com/tailor-platform/sdk/pull/2835) [`0d4cd79`](https://github.com/tailor-platform/sdk/commit/0d4cd79db4a02b162bf384881668abec264da539) Thanks [@dqn](https://github.com/dqn)! - `tailor remove` now deletes every resource it lists. Before, when the only remaining resources were sub-resources such as TailorDB types, resolvers, IdP clients, auth configs, or auth connections, it listed them without deleting them. It now also lists workflow job functions; before, they were deleted without being listed, and when nothing else remained they were not deleted at all. Deploy plans, including the `Plan:` summary counts and `--dry-run --json` `changes`, now list each workflow job function deletion as its own `jobFunction` entry, so removing a workflow shows and counts its job functions on separate lines.
+
+- [#2822](https://github.com/tailor-platform/sdk/pull/2822) [`b433a27`](https://github.com/tailor-platform/sdk/commit/b433a27e06c7aa1e2bc998b8f703aab6c9d8a7ff) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency @​politty/zod to v0.6.3
+
+- [#2823](https://github.com/tailor-platform/sdk/pull/2823) [`8712ec6`](https://github.com/tailor-platform/sdk/commit/8712ec645517d29c129b3da72e32bf0d71319b2c) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency execa to v10.2.1
+
+- [#2824](https://github.com/tailor-platform/sdk/pull/2824) [`5bf7e69`](https://github.com/tailor-platform/sdk/commit/5bf7e69611437fcf486b9964a7fc30d606cfa62a) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update @​opentelemetry
+
+- [#2826](https://github.com/tailor-platform/sdk/pull/2826) [`2a0e726`](https://github.com/tailor-platform/sdk/commit/2a0e726f3646394e36546eef9e56cfba8d043a09) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update @​opentelemetry to v3
+
+- [#2842](https://github.com/tailor-platform/sdk/pull/2842) [`8d3d70c`](https://github.com/tailor-platform/sdk/commit/8d3d70c78c22ea6cc4a98891bfddab880c83d830) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency es-toolkit to v1.53.0
+
+- [#2836](https://github.com/tailor-platform/sdk/pull/2836) [`95ba73c`](https://github.com/tailor-platform/sdk/commit/95ba73cf72500d0e41252112164f212fa189fad7) Thanks [@toiroakr](https://github.com/toiroakr)! - The Stripe example in the incoming webhook docs now shows where to verify the `stripe-signature` header against `rawBody`, and links to Stripe's verification steps. The docs and the `rawBody` type of `IncomingWebhookArgs` now say that `rawBody` is delivered base64-encoded and has to be decoded to the original bytes before computing a signature.
+
+- [#2832](https://github.com/tailor-platform/sdk/pull/2832) [`2c6242a`](https://github.com/tailor-platform/sdk/commit/2c6242a73f47cfb4a782449938b2323487aa0046) Thanks [@dqn](https://github.com/dqn)! - When a `.ts` or `.mts` file the CLI loads cannot be parsed, report a `SYNTAX_INVALID` error naming the file, the line, and the syntax error. For a TailorDB type, resolver, executor, workflow, HTTP adapter, or `function run` file, or a file one of them imports, this replaces `[object Object]`. For a config, or a file it imports, it replaces `UNEXPECTED_ERROR`, and the GitHub Actions annotation is titled `SYNTAX_INVALID` instead of `SyntaxError`.
+
 ## 2.35.0
 
 ### Minor Changes

package/dist/{application-Bj2MtL-d.mjs → application-83WVdH85.mjs}

@@ -1 +1 @@
-export{t as defineApplication,r as generatePluginFilesIfNeeded}from"./application-DIsQSnj3.mjs";
+export{t as defineApplication,r as generatePluginFilesIfNeeded}from"./application-Cida-j1g.mjs";