@tailor-platform/sdk 2.14.1 → 2.15.0

package/docs/cli/application.md

@@ -118,7 +118,7 @@ create one explicitly before requesting a deployment plan.
 
 **Config File Modification:**
 
-On first run, `deploy` automatically injects a stable `id: "<uuid>"` field into your `defineConfig({...})` call in `tailor.config.ts`. This UUID is used to track your application across renames so the SDK can recognize ownership across renames. Commit the generated id to version control. See [Configuration](../configuration.md#application-settings) for details.
+On the first local run, `deploy` assigns your application a stable id (a UUID) so the SDK can recognize ownership across renames. Projects that use `tailor setup` get it recorded in `.github/tailor.lock` under `appIds`; other projects get an `id: "<uuid>"` field written into the `defineConfig({...})` call in `tailor.config.ts`. Commit the file that received the id. See [Configuration](../configuration.md#application-settings) for details.
 
 **Multiple Config Deploys:**
 

package/docs/cli/function.md

@@ -83,12 +83,15 @@ tailor function logs [options] [execution-id]
 
 **Options**
 
-| Option                          | Alias | Description                                      | Required | Default  | Env                            |
-| ------------------------------- | ----- | ------------------------------------------------ | -------- | -------- | ------------------------------ |
-| `--workspace-id <WORKSPACE_ID>` | `-w`  | Workspace ID                                     | No       | -        | `TAILOR_PLATFORM_WORKSPACE_ID` |
-| `--profile <PROFILE>`           | `-p`  | Workspace profile                                | No       | -        | `TAILOR_PLATFORM_PROFILE`      |
-| `--order <ORDER>`               | -     | Sort order (asc or desc)                         | No       | `"desc"` | -                              |
-| `--limit <LIMIT>`               | `-l`  | Maximum number of items to return (0: unlimited) | No       | `50`     | -                              |
+| Option                          | Alias | Description                                                                                  | Required | Default  | Env                            |
+| ------------------------------- | ----- | -------------------------------------------------------------------------------------------- | -------- | -------- | ------------------------------ |
+| `--workspace-id <WORKSPACE_ID>` | `-w`  | Workspace ID                                                                                 | No       | -        | `TAILOR_PLATFORM_WORKSPACE_ID` |
+| `--profile <PROFILE>`           | `-p`  | Workspace profile                                                                            | No       | -        | `TAILOR_PLATFORM_PROFILE`      |
+| `--order <ORDER>`               | -     | Sort order (asc or desc)                                                                     | No       | `"desc"` | -                              |
+| `--limit <LIMIT>`               | `-l`  | Maximum number of items to return (0: unlimited)                                             | No       | `50`     | -                              |
+| `--follow`                      | `-f`  | Keep polling a running execution and print new log entries as they arrive (detail mode only) | No       | `false`  | -                              |
+| `--interval <INTERVAL>`         | `-i`  | Polling interval for --follow (e.g., '3s', '500ms', '1m')                                    | No       | `"3s"`   | -                              |
+| `--timeout <TIMEOUT>`           | `-t`  | Maximum time to keep following (e.g., '30s', '10m'); unbounded by default                    | No       | -        | -                              |
 
 See [Global Options](../cli-reference.md#global-options) for options available to all commands.
 
@@ -118,8 +121,18 @@ $ tailor function logs --json
 $ tailor function logs <execution-id> --json
 ```
 
+**Stream log entries of a running execution until it completes**
+
+```bash
+$ tailor function logs <execution-id> --follow
+```
+
 **Notes**
 
+Execution details include `logEntries`, the structured log lines (message, severity, timestamp) recorded while the function ran. They are available while the execution is still running, whereas the flat `logs` string is filled in only after completion. The human-readable view shows the structured entries when present and falls back to `logs` otherwise.
+
+Use `--follow` to keep polling a running execution and print new log entries as they arrive until it completes. Polling continues while the execution is suspended at a wait point, and indefinitely unless `--timeout` is set. On environments where no structured entries are returned, `--follow` shows the flat `logs` string once the execution completes. With `--json`, `--follow` waits for completion and then emits the final execution details once.
+
 When viewing a specific execution that failed, the command displays error details with the stack trace mapped back to your original source files (clickable file links and code snippets, matching `function run` output).
 
 Stack traces are mapped only when the execution includes a content hash for the exact build that ran. If the content hash is missing or the build is no longer available, the command falls back to a plain-text error display.

package/docs/cli/tailordb.md

@@ -119,17 +119,17 @@ tailor tailordb migration generate [options]
 
 **Options**
 
-| Option                                | Alias | Description                                                                                                                                                                                     | Required | Default              | Env                  |
-| ------------------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------- | -------------------- |
-| `--yes`                               | `-y`  | Skip confirmation prompts                                                                                                                                                                       | No       | `false`              | -                    |
-| `--config <CONFIG>`                   | `-c`  | Path to Tailor config file                                                                                                                                                                      | No       | `"tailor.config.ts"` | `TAILOR_CONFIG_PATH` |
-| `--name <NAME>`                       | `-n`  | Optional description for the migration                                                                                                                                                          | No       | -                    | -                    |
-| `--init`                              | -     | Delete existing migrations and start fresh                                                                                                                                                      | No       | `false`              | -                    |
-| `--data-only`                         | -     | Create a migration with no schema changes whose migration script runs a standalone data transformation                                                                                          | No       | `false`              | -                    |
-| `--namespace <NAMESPACE>`             | -     | Target TailorDB namespace for --data-only (required if multiple namespaces exist)                                                                                                               | No       | -                    | -                    |
-| `--rename <RENAME>`                   | -     | Record a field or table rename instead of remove + add (format: "Table.oldField:newField" or "OldTable:NewTable"; repeatable). Renames require a migration script that copies the data.         | No       | -                    | -                    |
-| `--drop <DROP>`                       | -     | Confirm that a removed field or table is a genuine removal, not a rename (format: "Table.field" or "Table"; repeatable). Required in non-interactive runs for a removal with rename candidates. | No       | -                    | -                    |
-| `--expand-contract <EXPAND_CONTRACT>` | -     | Convert a field type through a temporary field (format: "Table.field"; repeatable). Generates two migrations.                                                                                   | No       | -                    | -                    |
+| Option                                | Alias | Description                                                                                                                                                                                                                                 | Required | Default              | Env                  |
+| ------------------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------- | -------------------- |
+| `--yes`                               | `-y`  | Skip confirmation prompts                                                                                                                                                                                                                   | No       | `false`              | -                    |
+| `--config <CONFIG>`                   | `-c`  | Path to Tailor config file                                                                                                                                                                                                                  | No       | `"tailor.config.ts"` | `TAILOR_CONFIG_PATH` |
+| `--name <NAME>`                       | `-n`  | Optional description for the migration                                                                                                                                                                                                      | No       | -                    | -                    |
+| `--init`                              | -     | Delete existing migrations and start fresh                                                                                                                                                                                                  | No       | `false`              | -                    |
+| `--data-only`                         | -     | Create a migration with no schema changes whose migration script runs a standalone data transformation                                                                                                                                      | No       | `false`              | -                    |
+| `--namespace <NAMESPACE>`             | -     | Target TailorDB namespace for --data-only (required if multiple namespaces exist)                                                                                                                                                           | No       | -                    | -                    |
+| `--rename <RENAME>`                   | -     | Record a field, table, or nested member rename instead of remove + add (format: "Table.oldField:newField", "OldTable:NewTable", or "Table.field.oldMember:newMember"; repeatable). Renames require a migration script that copies the data. | No       | -                    | -                    |
+| `--drop <DROP>`                       | -     | Confirm that a removed field, table, or nested member is a genuine removal, not a rename (format: "Table.field", "Table", or "Table.field.member"; repeatable). Required in non-interactive runs for a removal with rename candidates.      | No       | -                    | -                    |
+| `--expand-contract <EXPAND_CONTRACT>` | -     | Convert a field type through a temporary field (format: "Table.field"; repeatable). Generates two migrations.                                                                                                                               | No       | -                    | -                    |
 
 See [Global Options](../cli-reference.md#global-options) for options available to all commands.
 

package/docs/configuration.md

@@ -21,19 +21,23 @@ To deploy the same config to multiple workspaces with per-environment values, se
 import { defineConfig } from "@tailor-platform/sdk";
 
 export default defineConfig({
-  // SDK-managed app id — do not edit, except when copying this config to a separate app.
-  // id: "<uuid>" — written here automatically on first run
   name: "my-app",
   cors: ["https://example.com"],
   allowedIpAddresses: ["192.168.1.0/24"],
   disableIntrospection: false,
   logLevel: process.env.TAILOR_APP_LOG_LEVEL ?? "DEBUG",
+  metadata: { "erp-kit-version": "v1-2-3" },
 });
 ```
 
 **Name**: Set the application name.
 
-**Id (auto-managed)**: A stable identifier used to recognize resources managed by the SDK across renames. On first `deploy`, the SDK injects an `id: "<uuid>"` field into your `defineConfig({...})` call and commits it to `tailor.config.ts`. Keep it under version control; do not edit it by hand. Delete it only if you want the SDK to assign a new id on the next `deploy` — typically when `tailor.config.ts` was copied from another project and the new application should not share the original's id. Auto-injection requires `defineConfig({...})` to be called with an inline object literal: if the argument is a separate variable (e.g. `defineConfig(config)`), or if `tailor.config.ts` is a wrapper that re-exports `defineConfig` from another file, the SDK cannot inject — add the `id` field manually to the file that contains the actual `defineConfig({...})` object literal.
+**Id (auto-managed)**: A stable identifier used to recognize resources managed by the SDK across renames. The SDK assigns it on the first local `deploy` and keeps it under version control for you; do not edit it by hand.
+
+- Projects that use [`tailor setup`](./github-actions.md#app-id) keep the id in `.github/tailor.lock`, under `appIds`, keyed by the config file's path. `tailor.config.ts` itself carries no id, so a config copied inside the repository gets its own id, and configs that re-export another file work as well.
+- Other projects get an `id: "<uuid>"` field written into the `defineConfig({...})` call. Delete it only if you want the SDK to assign a new id on the next `deploy` — typically when `tailor.config.ts` was copied from another project and the new application should not share the original's id. Writing the field requires `defineConfig({...})` to be called with an inline object literal: if the argument is a separate variable (e.g. `defineConfig(config)`), or if `tailor.config.ts` re-exports a config from another file, add the `id` field manually to the file that contains the actual `defineConfig({...})` object literal.
+
+When a project starts using `tailor setup`, the next local `deploy` or `setup` moves the id from `tailor.config.ts` into the lock and removes it from the config. `AppConfig.id` stays supported: a config `id` that agrees with the lock is accepted (a local `deploy` moves it into the lock; `deploy --dry-run`, `remove`, and CI remind you to remove it), and one that disagrees stops the command so you can decide which value to keep.
 
 **CORS**: Specify CORS settings as an array. You can also include Static Website URL references (e.g. `website.url`) in this array; see [Static Website](./services/staticwebsite.md).
 
@@ -41,6 +45,19 @@ export default defineConfig({
 
 **Disable Introspection**: Disable GraphQL introspection. Default is `false`.
 
+**Metadata**: Extra labels written to the deployed application's metadata on `deploy`, alongside the labels the SDK writes itself. Use it to record information that tooling reads back from the platform, such as the version of a framework the config is generated from. Keys must match `^[a-z][a-z0-9_-]{0,62}$` and must not start with `sdk-`; values must be empty or match the same pattern, so a version like `1.2.3` is written as `v1-2-3`. At most 17 entries can be set:
+
+```typescript
+const erpKitVersion = "1.2.3";
+
+export default defineConfig({
+  name: "my-app",
+  metadata: { "erp-kit-version": `v${erpKitVersion.replace(/\./g, "-")}` },
+});
+```
+
+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.
+
 **Log Level**: 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

@@ -208,22 +208,54 @@ planned.)
 ### `.github/tailor.lock`
 
 A machine-owned JSON file that tracks which files the SDK manages, the inputs
-they were generated from, and their content hashes. **Commit this file. Never
-edit it by hand.** The SDK uses it to recognize its own files on re-runs and to
-detect hand edits.
-
-### `tailor.config.ts` (id injection)
-
-If your config does not already have an `id` field, `setup` injects one.
-This `id` must be committed alongside the workflow file. In CI, `tailor
-deploy` refuses to inject a new id — if the id were assigned fresh on each CI
-run, every deploy would create a brand-new application and lose ownership of
-previously deployed resources.
+they were generated from, and their content hashes, plus the id of every app in
+the repository (see [App id](#app-id)). **Commit this file.** The SDK uses it to
+recognize its own files on re-runs and to detect hand edits. The only part
+meant for hand editing is `appIds`, and only to re-key an entry after moving an
+app directory or to delete the entry of a removed app.
+
+### App id
+
+Every application has a stable id (a UUID) that the SDK uses to recognize the
+resources it owns across renames. In a repository set up with `tailor setup`,
+the id lives in `.github/tailor.lock` under `appIds`, keyed by the config
+file's repository-relative path:
+
+```jsonc
+{
+  "version": 2,
+  "targets": [/* generated workflows */],
+  "appIds": {
+    "apps/order/tailor.config.ts": "d0a3398a-…",
+    "apps/billing/tailor.config.ts": "7f21c4e0-…",
+  },
+}
+```
 
+`setup` records the id when it generates a workflow, and a local `tailor
+deploy` records one for any config that has none yet. Because the key is the
+config path, renaming the app keeps its id, and copying a config to a new
+directory gives the copy a fresh id instead of the original's. If
+`tailor.config.ts` still has an `id` field from before, `setup` or a local
+`deploy` moves it into the lock and removes it from the config; a config `id`
+that disagrees with the lock stops the command so you can decide which value
+to keep.
+
+In CI, `tailor deploy` never assigns an id — if one were assigned fresh on
+each run, every deploy would create a brand-new application and lose ownership
+of previously deployed resources. A config without a recorded id fails the
+plan job with instructions to run `tailor deploy` locally and commit the lock.
 If your pipeline intentionally deploys a fresh, throwaway application on every
 run (for example an end-to-end test harness that creates and deletes its own
-workspace), set `TAILOR_CI_ALLOW_ID_INJECTION=true` to opt back
-into automatic id injection for that pipeline.
+workspace), set `TAILOR_CI_ALLOW_ID_INJECTION=true` to let CI assign one.
+
+When you move an app directory, its `appIds` entry still points at the old
+path. Locally, `deploy` and `setup` notice the single unmatched entry and ask
+whether the app was moved; answering yes re-keys the entry so the app keeps
+its id. In CI, or when more than one entry is unmatched, the command stops and
+asks you to re-key the entry (or delete entries of removed apps) by hand.
+Re-run the relevant `setup` subcommand as well so the workflow's paths follow
+the move.
 
 ## Secrets
 

package/docs/migration/v3.md

@@ -160,3 +160,41 @@ property, which is the relation's cardinality (e.g. "n-1", "1-1",
 ```
 
 </details>
+
+## String file uploads → explicit encoding
+
+**Migration:** Manual
+
+String inputs to the SDK `file.upload` and generated `uploadFile` require an explicit `encoding` in v3. Add `encoding: "utf8"` to preserve the previous behavior; use `"base64"` only when decoding the input is intended. Byte inputs are unchanged. This migration requires checking the input type and regenerating file helpers, so it provides review guidance instead of rewriting calls automatically.
+
+Before:
+
+```ts
+await file.upload(ns, table, field, id, text, { contentType: "text/plain" });
+```
+
+After:
+
+```ts
+await file.upload(ns, table, field, id, text, { contentType: "text/plain", encoding: "utf8" });
+```
+
+<details>
+<summary>Prompt for an AI agent (to perform this migration)</summary>
+
+```text
+Inspect calls to the imported SDK file.upload (including aliases and destructured upload)
+and generated uploadFile helpers, including shared wrappers and option objects.
+For string inputs, add encoding: utf8 to preserve existing text storage behavior.
+Choose encoding: base64 only if decoding is explicitly intended; never infer it from
+the string contents or contentType. Preserve all existing upload options.
+Leave byte-only inputs unchanged. For string | byte unions, supplying encoding: utf8
+preserves behavior because byte input ignores encoding. Narrow shared options types
+so TypeScript can see that encoding is present for strings.
+Run tailor generate to regenerate uploadFile helpers instead of editing generated files.
+The global tailordb.file.upload does not support this encoding option; switch to the
+file import from @tailor-platform/sdk/runtime before using it.
+Do not change unrelated upload APIs or already explicit encodings.
+```
+
+</details>

package/docs/runtime.md

@@ -43,6 +43,45 @@ const { url } = await aigateway.get("my-aigateway");
 logger.info("order processed", { orderId: "o-1", total: 99.5 });
 ```
 
+## Uploading files
+
+Pass bytes directly to `file.upload`. For strings, specify how to interpret the input:
+
+```ts
+import { file } from "@tailor-platform/sdk/runtime";
+
+await file.upload("my-namespace", "Document", "attachment", recordId, text, {
+  encoding: "utf8",
+  contentType: "text/plain",
+});
+
+await file.upload("my-namespace", "Document", "attachment", recordId, imageBase64, {
+  encoding: "base64",
+  contentType: "image/png",
+});
+```
+
+`encoding` controls the input string's interpretation; `contentType` describes the stored file.
+Setting `contentType: "image/png"` does not decode Base64. Byte arrays and buffers are uploaded
+unchanged, even when `encoding` is supplied. Omitting `contentType` with `encoding: "utf8"`
+stores the file as `text/plain; charset=utf-8`; omitting it with `"base64"` leaves the content
+type unset, unless the Base64 string is a `data:<contentType>;base64,<data>` URL, in which case
+`<contentType>` is used. An explicit `contentType` option always takes precedence over one
+found in a data URL.
+
+Base64 input may omit padding and contain ASCII whitespace. Invalid characters and invalid
+padding are rejected with `TypeError` before upload. Decoding Base64 does not validate the
+resulting file's format.
+
+Uploading a string without `encoding` still stores it as text, but that overload is deprecated
+and will be removed in v3. Add `encoding: "utf8"` to preserve existing behavior, or choose
+`"base64"` when decoding is intended. Calls with byte arrays or buffers are not deprecated.
+The generated `uploadFile` helper supports the same options; run `tailor generate` to update it.
+
+The encoding option is available on the imported SDK `file.upload` and generated helpers.
+For code using the global `tailordb.file.upload`, switch to the imported `file.upload` before
+using this option.
+
 ## Subpath imports
 
 Each namespace can also be imported individually so you only pull what you need:

package/docs/services/resolver.md

@@ -139,7 +139,9 @@ createResolver({
 
 GraphQL still accepts and returns `YYYY-MM-DD` strings. The SDK converts input to a `Date` at midnight UTC and formats output using its UTC year, month, and day. Use UTC getters and setters for date arithmetic; local getters and setters depend on the runtime's timezone. Any time component in the returned `Date` is discarded according to UTC, so `new Date("2026-09-07T00:00:00+09:00")` returns `"2026-09-06"`.
 
-This option also works in nested objects and with `array: true` or `optional: true`. Input must be a valid calendar date, and output must be a valid `Date` with a UTC year between 0000 and 9999. Both deployed resolvers and `tailor function run` perform these conversions.
+This option also works in nested objects and with `array: true` or `optional: true`. Input must be a valid calendar date, and output must be a valid `Date` with a 4-digit UTC year (0000-9999). Both deployed resolvers and `tailor function run` perform these conversions.
+
+An executor subscribing to the resolver with `resolverExecutedTrigger` receives the event as JSON, so `result` holds the `YYYY-MM-DD` string rather than a `Date`.
 
 ### Custom Type Name (`typeName`)
 

package/docs/services/tailordb-migration.md

@@ -164,15 +164,33 @@ During deploy, the pre-migration phase keeps the old field and adds the new fiel
 
 If you decline the prompt (or confirm the removal with `--drop`), the change stays a plain removal + addition with the usual data-loss warning.
 
-Renaming a member inside a **nested field** is not detected as a rename: `User.address.zip` → `zipCode` becomes a single `field_modified` on `address`, so no `field_renamed` change is recorded and no copy script is generated. The removed member is reported as a data-loss warning instead, which `migration validate --strict` picks up like any other warning; when a compatible member was added at the same level, the warning names it as a possible rename target:
+#### Renaming a member inside a nested field
+
+Members inside a **nested field** (`db.object(...)`) are detected the same way: when `migration generate` finds a member removed from a nested field and a compatible member added under the same parent, it asks whether the member was renamed. Two members qualify only when copying the value preserves it exactly, because nested member constraints other than the new member's requiredness and unique constraint are not relaxed: the type, array-ness, requiredness, foreign key target, decimal scale, hooks, and validations must match (index, unique, and vector may differ, as for a top-level rename), enum values may be added but not removed, an object-typed member must keep the same members recursively, and serial members never qualify.
+
+```
+? User.address.zip was removed and zipCode was added with a compatible type. Was it renamed to zipCode? (Y/n)
+```
+
+In non-interactive environments the command fails while a candidate is left unresolved, exactly like field renames. Resolve it with the nested member forms of the same flags (a value with two or more dots before the `:` targets a member; deeper members use their dotted path, and the new name is a single segment under the same parent):
+
+```bash
+tailor tailordb migration generate --rename "User.address.zip:zipCode"
+tailor tailordb migration generate --rename "User.address.geo.lat:latitude"
+tailor tailordb migration generate --drop "User.address.zip"
+```
+
+A confirmed rename is recorded on the nested field's `field_modified` change as `memberRenames` and treated as **breaking**, so a migration script is required. The generated `migrate.ts` reads every row's nested value, stores each renamed member under its new name (descending into arrays at every level), and writes the value back; the old member is kept in the written value because it stays on the schema until the post-migration phase drops it. During deploy, the pre-migration phase keeps the old member on the nested field and adds the new member as optional, the script copies the values, and the post-migration phase drops the old member and enforces the new member's requiredness.
+
+A member removed without a confirmed rename stays a data-loss warning, which `migration validate --strict` picks up like any other warning; when a compatible sibling was added, the warning names it and the `--rename` value that confirms the rename:
 
 ```
 Warning: data loss possible:
 
-  - User.address.zip: Nested member removed (existing values will no longer be accessible through the schema). Possibly renamed to zipCode: nested renames are not detected, so copy its values with a migration script if it was renamed
+  - User.address.zip: Nested member removed (existing values will no longer be accessible through the schema). Possibly renamed to zipCode: confirm it with --rename "User.address.zip:<newName>" to scaffold a copy script, or keep the removal and copy the values yourself
 ```
 
-To carry the values over, add a custom `tailordb migration script` to the migration. The pre-migration phase keeps the removed member on the nested field until the script finishes, exactly like a removed top-level field, so the script can read `zip` and write `zipCode`. Nested fields reach the script as objects, so the copy rewrites the whole `address` value; keep the old member in what you write, because it is still part of the schema until the post-migration phase drops it. Declare the new member as optional: the platform rejects a nested member that is required while existing records lack it, and nested member constraints are not relaxed during the pre-migration phase.
+The pre-migration phase keeps a removed member on the nested field until the script finishes, exactly like a removed top-level field, so a custom script can still read it. Nested fields reach the script as objects. Renaming a nested member cannot be combined in one migration with renaming its table or the nested field itself, and an object-typed member cannot be renamed in the same migration as one of its own members; split such changes into separate migrations (rename the object first, then its member).
 
 ### Renaming a table
 
@@ -261,7 +279,7 @@ export default defineConfig({
 
 ### Migration file format compatibility
 
-Migration files are versioned independently of the SDK package. This SDK writes format version `3` and reads versions `1` through `3`. It normalizes supported older formats in memory; it never rewrites applied migration files on disk.
+Migration files are versioned independently of the SDK package. This SDK writes format version `6` and reads versions `1` through `6`. It normalizes supported older formats in memory; it never rewrites applied migration files on disk. Format version `6` records renames of members inside nested fields (`memberRenames`); older SDK versions refuse to read it rather than deploying such a migration without the copy step.
 
 If a future SDK can no longer replay an old migration format, re-baseline while using an SDK version that still supports the complete history, commit the new baseline, deploy it to every environment, and then upgrade the SDK. A file from a newer unsupported format instead requires upgrading the SDK first. The CLI rejects both cases with guidance rather than attempting a best-effort replay.
 
@@ -348,6 +366,8 @@ The `env` values are injected at bundle time (the same mechanism as resolvers/ex
 | Add required field                | Yes       | Yes               | Script populates default values                                                                                                                                                                                                                    |
 | Remove field                      | No        | Optional          | Warning tier — no script is auto-generated, but you can add one with `tailordb migration script` to preserve or clear data before the field leaves the active schema. The field stays readable from `migrate.ts` during Pre-migration.             |
 | Rename field                      | Yes       | Yes               | Confirmed interactively at generate time or via `--rename "Table.oldField:newField"` — see [Renaming a field](#renaming-a-field). Auto-generated script copies values from the old field to the new one; both fields coexist during Pre-migration. |
+| Remove nested member              | No        | Optional          | Warning tier — see [Renaming a member inside a nested field](#renaming-a-member-inside-a-nested-field). The member stays readable from `migrate.ts` during Pre-migration.                                                                          |
+| Rename nested member              | Yes       | Yes               | Confirmed interactively at generate time or via `--rename "Table.field.oldMember:newMember"`. Auto-generated script rewrites each row's nested value; the old member stays readable and the new member is optional during Pre-migration.           |
 | Change optional → required        | Yes       | Yes               | Script sets defaults for null values                                                                                                                                                                                                               |
 | Change required → optional        | No        | No                | Schema change only                                                                                                                                                                                                                                 |
 | Add index (non-unique)            | No        | No                | Schema change only                                                                                                                                                                                                                                 |
@@ -552,7 +572,7 @@ When you run `tailor deploy`, the SDK detects pending migrations (anything past
 
 For each pending migration:
 
-1. **Pre-migration**: Schema changes that would be breaking are applied in a relaxed form first. A verified in-place field type change keeps its complete previous field contract until Post-migration, including field and table-level hooks or validators changed by the same migration. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the table so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped); members removed from a nested field are kept the same way. For a renamed field, the old field is kept and the new field is added with its constraints relaxed, so the script can read the old field and write the new one. For a renamed table, the new table is created with its full constraints while the old table stays on the namespace until post-migration cleanup, so the script can copy rows between them. Breaking table-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
+1. **Pre-migration**: Schema changes that would be breaking are applied in a relaxed form first. A verified in-place field type change keeps its complete previous field contract until Post-migration, including field and table-level hooks or validators changed by the same migration. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the table so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped); members removed from a nested field are kept the same way, and the new member of a confirmed nested rename is added as optional and non-unique. For a renamed field, the old field is kept and the new field is added with its constraints relaxed, so the script can read the old field and write the new one. For a renamed table, the new table is created with its full constraints while the old table stays on the namespace until post-migration cleanup, so the script can copy rows between them. Breaking table-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
 2. **Script execution**: If `migrate.ts` exists on disk for this migration, it is bundled and sent to the platform via the script execution API and runs as the configured machine user inside a transaction. The script is hard-required for breaking changes (`diff.requiresMigrationScript`) — deploy fails if the file is missing, unless a `--no-script` acknowledgment was recorded (see [Breaking changes without a script](#breaking-changes-without-a-script)). It is also executed when present for warning-tier diffs — see [Warnings and optional migration scripts](#warnings-and-optional-migration-scripts).
 3. **Post-migration schema**: Required constraints and the target field definitions are applied. Do not assume that removing a field clears its underlying stored JSON value.
 4. **Checkpoint and cleanup**: The `sdk-migration` label is bumped to this migration's number, then removed GQL permissions and tables — including the old table left behind by a rename — are deleted. Advancing the checkpoint first prevents a failed checkpoint write from requiring the SDK to recreate irreversibly deleted records.

package/docs/testing.md

@@ -59,7 +59,7 @@ export default defineConfig({
 `tailorRuntime()` provides:
 
 1. **Node.js module blocking** — `import { randomBytes } from "node:crypto"` in production code throws an error with a suggestion for the Web Standard API alternative (`globalThis.crypto`). Test files (`*.test.ts`, `*.spec.ts`) are exempt.
-2. **Node.js globals removal** — Only globals available in the platform runtime are kept (whitelist). `Buffer`, `global`, `setImmediate`, `__dirname`, `__filename`, `performance`, and others are removed.
+2. **Node.js globals removal** — Only globals available in the platform runtime are kept (whitelist). `Buffer`, `global`, `setImmediate`, `__dirname`, `__filename`, and others are removed.
 3. **Platform API mocks** — the platform error classes (`TailorErrors`, `TailorDBFileError`) and `tailor.context` are always available. The other namespaces (`tailordb.Client`, `tailor.workflow`, `tailor.secretmanager`, …) are mocked when you acquire the corresponding `mockX()` — see below.
 
 ### Acquiring mocks with `using`
@@ -452,12 +452,7 @@ export default defineConfig({
   plugins: [tailorRuntime()],
   test: {
     projects: [
-      // `extends: true` is required so each project inherits the root-level
-      // `tailorRuntime()` plugin (transform hook + injected setup file).
-      // Without it, only the environment name rewrite applies — node:* import
-      // blocking and per-test global cleanup will silently not run.
       {
-        extends: true,
         test: {
           name: "unit",
           environment: "tailor-runtime",
@@ -465,7 +460,6 @@ export default defineConfig({
         },
       },
       {
-        extends: true,
         test: {
           name: "e2e",
           include: ["e2e/**/*.test.ts"],
@@ -477,6 +471,8 @@ export default defineConfig({
 });
 ```
 
+Inline projects inherit the root-level `tailorRuntime()` plugin by default on Vitest 5. On Vitest 4, add `extends: true` to each project; without it, `node:*` import blocking silently does not run.
+
 ### Known Limitations
 
 - **`process` and `require`** are not removed or blocked. Vitest's internal runner depends on them extensively. On the real platform runtime, they do not exist.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.14.1",
+  "version": "2.15.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -165,6 +165,7 @@
     "@opentelemetry/sdk-trace-node": "2.11.0",
     "@opentelemetry/semantic-conventions": "1.43.0",
     "@oxc-project/types": "0.148.0",
+    "@politty/zod": "0.2.1",
     "@secretlint/core": "13.0.5",
     "@secretlint/secretlint-rule-preset-recommend": "13.0.5",
     "@standard-schema/spec": "1.1.0",
@@ -173,13 +174,13 @@
     "@toiroakr/read-multiline": "0.4.1",
     "@urql/core": "6.0.3",
     "amaro": "1.1.11",
-    "confbox": "0.2.4",
+    "confbox": "0.3.1",
     "date-fns": "4.4.0",
     "es-toolkit": "1.52.0",
     "find-up-simple": "1.0.1",
     "get-east-asian-width": "1.6.0",
     "get-tsconfig": "4.14.3",
-    "globals": "17.11.0",
+    "globals": "17.12.0",
     "graphql": "17.0.2",
     "inflection": "3.0.2",
     "kysely": "0.29.5",
@@ -190,7 +191,6 @@
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.3.2",
-    "politty": "0.11.9",
     "rolldown": "1.2.7",
     "semver": "7.8.5",
     "sql-highlight": "6.1.0",
@@ -208,7 +208,7 @@
     "@types/node": "24.13.3",
     "@types/semver": "7.8.0",
     "@typescript/native-preview": "7.0.0-dev.20260707.2",
-    "@vitest/coverage-v8": "4.1.11",
+    "@vitest/coverage-v8": "5.0.0",
     "eslint-plugin-zod": "4.12.0",
     "oxfmt": "0.66.0",
     "oxlint": "1.81.0",
@@ -216,8 +216,8 @@
     "sonda": "0.14.0",
     "tsdown": "0.23.0",
     "typescript": "6.0.3",
-    "vitest": "4.1.11",
-    "zinfer": "0.2.8"
+    "vitest": "5.0.0",
+    "zinfer": "0.4.5"
   },
   "peerDependencies": {
     "@electric-sql/pglite": ">=0.2.0",

package/dist/application-BWOMdL3D.mjs

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