@tailor-platform/sdk 2.36.0 → 2.38.0

package/CHANGELOG.md

@@ -1,5 +1,137 @@
 # @tailor-platform/sdk
 
+## 2.38.0
+
+### Minor Changes
+
+- [#2921](https://github.com/tailor-platform/sdk/pull/2921) [`e1b9d5f`](https://github.com/tailor-platform/sdk/commit/e1b9d5fa974b0f770728c7f04b03706896211bf7) Thanks [@dqn](https://github.com/dqn)! - `tailor tailordb migration validate` now fails, with the error code `tailor deploy` reports, when a migration an earlier deploy left in progress would stop the next deploy, and accepts `--migration-skip-steps` to check the steps to skip the way `tailor deploy` does
+
+- [#2869](https://github.com/tailor-platform/sdk/pull/2869) [`8c8ae7d`](https://github.com/tailor-platform/sdk/commit/8c8ae7df02f8c4394988e21d5bda0acc657f1e97) Thanks [@mocchira](https://github.com/mocchira)! - After a command finishes in an interactive terminal, `tailor` now lists your unread WARNING and CRITICAL platform notifications briefly on stderr, with pointers to `tailor notification list` and `tailor notification read <id>`. A CRITICAL notification is listed ahead of newer WARNINGs. It is best effort: the lookup runs alongside the command, and if it has not answered when the command ends, `tailor` waits at most 150 ms more before dropping it. It never changes a command's exit code, and it marks nothing read. It keeps appearing after each command until you read the notifications with `tailor notification read` or dismiss them. After a failed lookup it pauses for 5 minutes, so a platform outage does not cost a request per command. It is never shown in CI, under `--json`, in a pipe, or after help output. It is also skipped after `login`, `logout`, `auth`, `api`, `query` and the `notification` commands themselves, and after commands that only work locally: `init`, `generate`, `show`, `plugin`, `skills`, `completion`, `crashreport`, `upgrade`, `profile`, `open`, and `user` other than `user pat`. Set `TAILOR_NOTIFICATION_BANNER=off` to turn it off.
+
+- [#2868](https://github.com/tailor-platform/sdk/pull/2868) [`8369949`](https://github.com/tailor-platform/sdk/commit/8369949dc63974b0174b71cafe85ebe74b1eddb2) Thanks [@mocchira](https://github.com/mocchira)! - New `tailor notification` commands read the platform notifications sent to you (alerts, incidents, maintenance notices and announcements), the same inbox the Console shows:
+  
+  - `tailor notification list` lists your inbox, with `--category`, `--severity`, `--unread`, `--scope-workspace` and `--scope-organization` filters and shows the 50 newest by default (`--limit N` to change it, `--limit 0` for all).
+  - `tailor notification read <id...>` prints a notification (title, metadata, body, and action links, with Console paths given as full Console URLs) and marks it read; `--no-mark-read` only displays it. IDs that are not found are reported after the others are shown, and a read-only login shows notifications without marking them read.
+  - `tailor notification dismiss <id>` removes a notification from your inbox. This cannot be undone, so it is refused on a read-only profile.
+  
+  All three support `--json`.
+
+- [#2895](https://github.com/tailor-platform/sdk/pull/2895) [`0c15750`](https://github.com/tailor-platform/sdk/commit/0c1575093b5aba8dc47296a66513f1c500f72cfb) Thanks [@dqn](https://github.com/dqn)! - The CLI now loads `--env-file` and `--env-file-if-exists` before it reads its options, so values from an env file fill every option backed by an environment variable, the same as shell variables: for example `--config` from `TAILOR_CONFIG_PATH`, `--organization-id` from `TAILOR_PLATFORM_ORGANIZATION_ID` in `organization` commands, and the client ID and secret of `login --machine-user`. Previously these options kept their defaults or failed validation. A repeated `--env-file` now loads every file instead of only the last one; `createCommonArgs()` parses both options as string arrays. CLI plugins can load env files the same way by calling the new `loadEnvFilesFromArgv` export of `@tailor-platform/sdk/cli` from their `setup` hook, passing it the options they give `createCommonArgs()`. `deploy`, `workspace create`, and `tailordb migration test` now also ignore an empty `TAILOR_PLATFORM_ORGANIZATION_ID` or `TAILOR_PLATFORM_FOLDER_ID` set in the shell, as they already did for one loaded from an env file; an organization or folder ID that is not a UUID now fails `tailordb migration test` with `OPTIONS_INVALID` instead of `INVALID_ARGUMENTS`. When a CLI plugin is given an env file, `tailor` also loads it before dispatching, so a `TAILOR_CONFIG_PATH` in the file reaches the plugin instead of the config file found from the current directory.
+
+- [#2911](https://github.com/tailor-platform/sdk/pull/2911) [`91311ea`](https://github.com/tailor-platform/sdk/commit/91311ea1b25ca0832bda901e65fcb554d0bc52b1) Thanks [@dqn](https://github.com/dqn)! - **Breaking change (beta)**: Remove `tailor tailordb migration set`. It moved a namespace's migration checkpoint without changing its tables, so the checkpoint could stop matching the tables and the next deploy stopped with `MIGRATION_REMOTE_DRIFT`. Use `tailor tailordb migration sync <N>` instead: when the tables already match migration `<N>`, only the checkpoint changes, and `--force` replaces another migration history ID as `set --force` did. To re-run a failed migration in a development workspace, run `tailor tailordb migration sync <previous>`, which also removes the fields the failed migration added and deletes the tables it added together with their data. Settle a migration that an earlier deploy left in progress with `tailor tailordb migration resolve --complete` or `--rollback`. Errors and documentation that suggested `set` now suggest `sync`.
+
+### Patch Changes
+
+- [#2897](https://github.com/tailor-platform/sdk/pull/2897) [`5cb6958`](https://github.com/tailor-platform/sdk/commit/5cb695867cdcd6359c7c0fce2434906af60335f7) Thanks [@dqn](https://github.com/dqn)! - `tailor setup ci preview` now deletes the preview workspace of a pull request closed with merge conflicts, which GitHub never ran the preview workflow's cleanup for. Cleanup moves into a separate workflow, `tailor-<name>-preview-cleanup.yml`, which starts on `pull_request_target` and runs only the default branch's code. Run `tailor setup update` to regenerate existing preview workflows: the `tailor-preview-cleanup` job moves into the new workflow together with the steps and settings you added to it, and `setup update` stops if a job of yours `needs` it. A job of yours in the preview workflow that runs when the pull request is closed no longer runs; `setup` warns about each one whose `if` contains an `== 'closed'` comparison, so you can move it into the cleanup workflow. Commit the new workflow to the default branch, since GitHub runs it from there, and allow the default branch in the target's GitHub Environment if it restricts which branches can deploy.
+
+- [#2942](https://github.com/tailor-platform/sdk/pull/2942) [`734bf30`](https://github.com/tailor-platform/sdk/commit/734bf3090744eaaacc9a07872190534a67ed845e) Thanks [@dqn](https://github.com/dqn)! - The CLI now retries a Platform request, such as creating a workspace or applying a resource during `tailor deploy`, when the connection closes before a secure connection is established, instead of failing with `Client network socket disconnected before secure TLS connection was established`
+
+- [#2843](https://github.com/tailor-platform/sdk/pull/2843) [`748a0d6`](https://github.com/tailor-platform/sdk/commit/748a0d686bc3863fd3796aa3b984823e1065a7f9) Thanks [@toiroakr](https://github.com/toiroakr)! - Improve SQL and GraphQL syntax highlighting in the `query` REPL and make the REPL start faster.
+
+- [#2843](https://github.com/tailor-platform/sdk/pull/2843) [`345da01`](https://github.com/tailor-platform/sdk/commit/345da01d5918578e265013c96d1d7e6e9a4fba74) Thanks [@toiroakr](https://github.com/toiroakr)! - An executor whose GraphQL operation passes a `DocumentNode`, such as the result of `parse()` from `graphql` or a `gql` tagged template, to `query` now deploys it as the printed GraphQL query. It was deployed as the text `[object Object]`, which is not a valid GraphQL query. Passing the query as a string is unchanged.
+
+- [#2843](https://github.com/tailor-platform/sdk/pull/2843) [`aca6f28`](https://github.com/tailor-platform/sdk/commit/aca6f28f73294b88549fe1815230435d042b0f01) Thanks [@toiroakr](https://github.com/toiroakr)! - The SDK no longer installs `graphql`, `@urql/core`, or `wonka` as dependencies. The `DocumentNode` type that HTTP adapter `input` handlers and the executor `query` option accept is now included in the SDK's type declarations, so a project without `graphql` still gets `query` type-checked, and documents typed with `graphql` 16 or 17, including `TypedDocumentNode`, keep type-checking. If your project imports `graphql`, `@urql/core`, or `wonka` without declaring it, which only works when your package manager hoists it, add it to your own dependencies. If you use `graphql` 15 with `skipLibCheck: true`, passing a `parse()` result to the executor `query` option is now a type error, as it already was for HTTP adapters.
+
+- [#2914](https://github.com/tailor-platform/sdk/pull/2914) [`53c8474`](https://github.com/tailor-platform/sdk/commit/53c84745fcb2b65a1171900c6ec628819364324e) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` no longer stops with `MIGRATION_REMOTE_DRIFT` when an earlier deploy left a migration's pre-migration schema changes or maintenance mode in place without recording the migration as in progress, for example because it stopped right after those changes or could not roll them back. It runs that migration again from the start. `tailor tailordb migration resolve --rollback` returns such a namespace to its checkpoint without deploying, and `tailor tailordb migration validate` reports it as valid.
+
+- [#2925](https://github.com/tailor-platform/sdk/pull/2925) [`77c7bed`](https://github.com/tailor-platform/sdk/commit/77c7bedde797fb49c1633aa0601765b7f51e0d2b) Thanks [@dqn](https://github.com/dqn)! - `tailor tailordb migration validate` now also fails, with the error code `tailor deploy` reports, when a pending migration script has no machine user to run it or cannot be bundled
+
+- [#2932](https://github.com/tailor-platform/sdk/pull/2932) [`58eec18`](https://github.com/tailor-platform/sdk/commit/58eec1816ed7483d0d4fec484e0dddd3ff033272) Thanks [@dqn](https://github.com/dqn)! - `errorToJson` from `@tailor-platform/sdk/cli` now returns the envelope that `serializeError` writes, so its result can be embedded in JSON output: string values come without colors and with registered secrets redacted, and a context that cannot be written as JSON is left out along with the stack
+
+- [#2940](https://github.com/tailor-platform/sdk/pull/2940) [`70d504e`](https://github.com/tailor-platform/sdk/commit/70d504ec8e05e83bb9ebf0788510c4fbf6279578) Thanks [@dqn](https://github.com/dqn)! - `.serial()` formats with an octal `%o` specifier or a literal `%%` now reproduce in the PGlite schema: `tailor generate` with `kyselyTypePlugin({ pgliteSchemaPath })` no longer fails on them, `tailor tailordb migration generate` writes `db.pglite.ts`, and `tailor tailordb migration script --with-test` also writes `migrate.pglite.test.ts`.
+
+- [#2916](https://github.com/tailor-platform/sdk/pull/2916) [`b1f5a4b`](https://github.com/tailor-platform/sdk/commit/b1f5a4b19392bcdd14f7e4cb695a1b6d4d124c7d) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now finishes deleting the tables a migration removed when an earlier deploy committed that migration but failed or was interrupted before deleting them, instead of stopping with remote schema drift until you delete them by hand. The deploy lists those tables among its deletions and deletes them with their data after confirmation, and `tailor tailordb migration validate` reports them as tables the next deploy deletes.
+
+- [#2882](https://github.com/tailor-platform/sdk/pull/2882) [`9bf90bb`](https://github.com/tailor-platform/sdk/commit/9bf90bb9d1bf818ac3a294b3fe9ed68301b7eb2f) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency amaro to v1.3.0
+
+- [#2905](https://github.com/tailor-platform/sdk/pull/2905) [`bc3dd45`](https://github.com/tailor-platform/sdk/commit/bc3dd45ccbb67641f9c7636594a4fdcda963dd4e) Thanks [@renovate](https://github.com/apps/renovate)! - chore(deps): update dependency @​types/node to v26.6.6
+
+- [#2910](https://github.com/tailor-platform/sdk/pull/2910) [`dd0cd4f`](https://github.com/tailor-platform/sdk/commit/dd0cd4fd422909ee99921dbc4b22aed863c901f8) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency confbox to v0.3.2
+
+- [#2929](https://github.com/tailor-platform/sdk/pull/2929) [`173d9d2`](https://github.com/tailor-platform/sdk/commit/173d9d2f3830fff04e90d64600f71fa16d3dd221) Thanks [@renovate](https://github.com/apps/renovate)! - fix(deps): update dependency es-toolkit to v1.53.1
+
+- [#2924](https://github.com/tailor-platform/sdk/pull/2924) [`0c7fed1`](https://github.com/tailor-platform/sdk/commit/0c7fed120e25fdfea9c71f2035c74870b92fc7b2) Thanks [@dqn](https://github.com/dqn)! - Apply local TailorDB table definitions that the pending migrations do not include in the same `tailor deploy --no-schema-check` run, once the migrations complete, instead of leaving them to the next deploy. The deploy lists those tables, and fails with `MIGRATION_LOCAL_DEFINITIONS_FAILED` after the migrations are applied when one of them cannot be applied.
+
+- [#2913](https://github.com/tailor-platform/sdk/pull/2913) [`b7ffa31`](https://github.com/tailor-platform/sdk/commit/b7ffa31245abac1fb97dbfc51768bc55a2ce2dfa) Thanks [@dqn](https://github.com/dqn)! - The `tailor tailordb migration generate` and `tailor deploy` commands that `tailor tailordb migration rebaseline` suggests now pass `--config` the way its other suggested commands do: relative to the current directory, and omitted for the default config. They passed the config file's absolute path before.
+
+- [#2920](https://github.com/tailor-platform/sdk/pull/2920) [`a84ad7e`](https://github.com/tailor-platform/sdk/commit/a84ad7eb033dc5d687c1cea8a8fcd9238ebad27a) Thanks [@dqn](https://github.com/dqn)! - Fix `.start()` calls in a workflow, resolver, or executor file that declares its own `tailor` (for example, a workflow job exported as `tailor`), which failed at runtime after deploy.
+
+- [#2915](https://github.com/tailor-platform/sdk/pull/2915) [`d385bbb`](https://github.com/tailor-platform/sdk/commit/d385bbbb122eafbdef90f00d8464fc04ee6f58cd) Thanks [@dqn](https://github.com/dqn)! - `tailor deploy` now resumes a multi-step migration whose earlier deploy stopped during or after the post-migration schema changes but before recording the checkpoint, for example because the process was killed or the checkpoint write failed. It used to stop with `MIGRATION_REMOTE_DRIFT` on the tables that already had the post-migration schema, until `tailor tailordb migration resolve --complete` settled the migration or a deploy ran with `--no-schema-check`. Each table may now have either the pre-migration or the post-migration schema of that migration, and `tailor tailordb migration validate` accepts the same. The warning for a checkpoint write that could not be confirmed now says to deploy again for such a migration instead of to repair the checkpoint.
+
+- [#2919](https://github.com/tailor-platform/sdk/pull/2919) [`287925a`](https://github.com/tailor-platform/sdk/commit/287925ab6dd1d222ba55ee327bb196d6f761115e) Thanks [@dqn](https://github.com/dqn)! - `.unique()` on a field with a `keyOnly` relation is now kept. Before, the relation silently dropped it, so the field was deployed without a unique constraint, and a relation that used the field as its `toward.key` failed with `which must be unique`. The PGlite schema that `kyselyTypePlugin` and the migration `db.pglite.ts` generate, and the seed schema that `seedPlugin` generates, now declare the constraint too. After upgrading, a deployed table with such a field gains the unique constraint on its next `tailor deploy`; if stored rows hold duplicate values for the field, that deploy fails until the duplicate rows are updated to distinct values or deleted. In a namespace with `migration.directory`, `tailor deploy` stops with `MIGRATION_SCHEMA_CHECK_FAILED` until `tailor tailordb migration generate` creates the migration, and until the `TODO()` in its `migrate.ts`, which sets a new value on each duplicate row, is replaced. The new value must also be a key that exists in the referenced table.
+
+## 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

package/dist/{application-DaJbleMi.mjs → application-Bz80INH4.mjs}

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