@tailor-platform/sdk 1.45.2 → 1.47.0

package/docs/cli-reference.md

@@ -43,10 +43,10 @@ Both `--env-file` and `--env-file-if-exists` can be specified multiple times and
 
 ```bash
 # Load .env (required) and .env.local (optional, if exists)
-tailor-sdk apply --env-file .env --env-file-if-exists .env.local
+tailor-sdk deploy --env-file .env --env-file-if-exists .env.local
 
 # Load multiple files
-tailor-sdk apply --env-file .env --env-file .env.production
+tailor-sdk deploy --env-file .env --env-file .env.production
 ```
 
 ## Environment Variables
@@ -99,7 +99,7 @@ Commands for managing Tailor Platform applications (work with `tailor.config.ts`
 | ----------------------------------------------- | ------------------------------------------------------------------- |
 | [init](./cli/application.md#init)               | Initialize a new project using create-sdk.                          |
 | [generate](./cli/application.md#generate)       | Generate files using Tailor configuration.                          |
-| [apply](./cli/application.md#apply)             | Apply Tailor configuration to deploy your application.              |
+| [deploy](./cli/application.md#deploy)           | Deploy your application by applying the Tailor configuration.       |
 | [remove](./cli/application.md#remove)           | Remove all resources managed by the application from the workspace. |
 | [show](./cli/application.md#show)               | Show information about the deployed application.                    |
 | [open](./cli/application.md#open)               | Open Tailor Platform Console.                                       |
@@ -255,14 +255,14 @@ Commands for managing and deploying static websites.
 | [staticwebsite list](./cli/staticwebsite.md#staticwebsite-list)     | List all static websites in a workspace.              |
 | [staticwebsite get](./cli/staticwebsite.md#staticwebsite-get)       | Get details of a specific static website.             |
 
-### [Crash Report Commands](./cli/crash-report.md)
+### [Crash Report Commands](./cli/crashreport.md)
 
 Commands for managing crash reports.
 
-| Command                                                      | Description                                    |
-| ------------------------------------------------------------ | ---------------------------------------------- |
-| [crash-report list](./cli/crash-report.md#crash-report-list) | List local crash report files.                 |
-| [crash-report send](./cli/crash-report.md#crash-report-send) | Submit a crash report to help improve the SDK. |
+| Command                                                   | Description                                    |
+| --------------------------------------------------------- | ---------------------------------------------- |
+| [crashreport list](./cli/crashreport.md#crashreport-list) | List local crash report files.                 |
+| [crashreport send](./cli/crashreport.md#crashreport-send) | Submit a crash report to help improve the SDK. |
 
 ### [Setup Commands](./cli/setup.md)
 

package/docs/quickstart.md

@@ -16,7 +16,7 @@ The SDK requires Node.js 22 or later. Install Node.js via your package manager b
 
 Alternatively, you can use [Bun](https://bun.sh/) as the runtime.
 
-> **Note:** Bun has a known issue with HTTP/2 connections that may cause intermittent failures during `apply` or `generate` commands ([bun#14249](https://github.com/oven-sh/bun/issues/14249), [bun#26719](https://github.com/oven-sh/bun/issues/26719)). If you encounter a connection error, retry the command.
+> **Note:** Bun has a known issue with HTTP/2 connections that may cause intermittent failures during `deploy` or `generate` commands ([bun#14249](https://github.com/oven-sh/bun/issues/14249), [bun#26719](https://github.com/oven-sh/bun/issues/26719)). If you encounter a connection error, retry the command.
 
 ### Create an Example App
 
@@ -46,7 +46,7 @@ npx tailor-sdk workspace list
 
 ### Deploy Your App
 
-Run the apply command to deploy your project:
+Run the deploy command to deploy your project:
 
 ```bash
 cd example-app

package/docs/services/auth.md

@@ -388,7 +388,7 @@ export const auth = defineAuth("my-auth", {
 });
 ```
 
-After `tailor-sdk apply`, authorize the connection:
+After `tailor-sdk deploy`, authorize the connection:
 
 ```bash
 tailor-sdk authconnection authorize --name google-connection \
@@ -448,7 +448,7 @@ tailor-sdk authconnection list
 tailor-sdk authconnection revoke --name google-connection
 ```
 
-Connection creation is handled by `tailor-sdk apply` via the config.
+Connection creation is handled by `tailor-sdk deploy` via the config.
 
 See [Auth Resource Commands](../cli/auth.md) for full CLI documentation.
 

package/docs/services/secret.md

@@ -34,11 +34,11 @@ Secrets are key-value pairs stored within a vault. Secret values are encrypted a
 
 ## Managing Secrets
 
-There are two ways to manage secrets: declaratively via `defineSecretManager()` in `tailor.config.ts`, or imperatively via the [CLI](#cli-management). Management is scoped per vault — **do not mix both approaches for the same vault**. When a vault is defined in config, the config becomes the source of truth: any secrets in that vault not present in the config will be deleted on `tailor-sdk apply`.
+There are two ways to manage secrets: declaratively via `defineSecretManager()` in `tailor.config.ts`, or imperatively via the [CLI](#cli-management). Management is scoped per vault — **do not mix both approaches for the same vault**. When a vault is defined in config, the config becomes the source of truth: any secrets in that vault not present in the config will be deleted on `tailor-sdk deploy`.
 
 ### Declarative Configuration
 
-Define your secrets in `tailor.config.ts` using `defineSecretManager()`. Each key is a vault name, and its value is a record of secret names to their values. These values are deployed to each vault on `tailor-sdk apply`.
+Define your secrets in `tailor.config.ts` using `defineSecretManager()`. Each key is a vault name, and its value is a record of secret names to their values. These values are deployed to each vault on `tailor-sdk deploy`.
 
 Since secret values should not be committed to source control, use environment variables:
 
@@ -87,7 +87,7 @@ When `ignoreNullishValues: true`:
 - Skipped secrets are shown in the deploy output for visibility
 - Secrets removed from the config entirely are still deleted (orphan cleanup)
 
-This allows you to set secret values once (e.g., via local `tailor-sdk apply` or the CLI) and then deploy from CI without needing the actual values in CI environment variables.
+This allows you to set secret values once (e.g., via local `tailor-sdk deploy` or the CLI) and then deploy from CI without needing the actual values in CI environment variables.
 
 ## Using Secrets
 
@@ -175,7 +175,7 @@ At runtime, these references are replaced with the actual secret values.
 
 Use the CLI to manage vaults that are **not** defined in `defineSecretManager()`. If you attempt to modify a vault that is managed by the config, the CLI will show a warning and ask for confirmation. Once confirmed, the CLI releases the vault's ownership label so it is no longer managed by config.
 
-After ownership is released, the next `tailor-sdk apply` will treat the vault as an unmanaged resource and prompt for confirmation before taking any action on it.
+After ownership is released, the next `tailor-sdk deploy` will treat the vault as an unmanaged resource and prompt for confirmation before taking any action on it.
 
 ### Create a Vault
 

package/docs/services/tailordb-migration.md

@@ -12,7 +12,7 @@ For the CLI command reference, see [`tailordb migration`](../cli/tailordb.md#tai
 
 - **Local snapshot–based diff detection** — each migration is generated by diffing your current type definitions against the previous snapshot stored in `migrations/<NNNN>/`.
 - **Transaction-wrapped data migrations** — each `migrate.ts` script runs inside a database transaction on the platform; if the script throws, all changes in that migration roll back.
-- **Automatic execution during `apply`** — `tailor-sdk apply` detects pending migrations, runs the two-stage type update (pre-migration → script → post-migration), and updates the migration checkpoint label.
+- **Automatic execution during `apply`** — `tailor-sdk deploy` detects pending migrations, runs the two-stage type update (pre-migration → script → post-migration), and updates the migration checkpoint label.
 - **Type-safe scripts** — the generated `db.ts` provides Kysely types that reflect the schema state **before** the migration runs, so transformations are written against the actual data shape.
 
 **Files in `migrations/`**
@@ -45,7 +45,7 @@ When you start with no `migrations/` directory:
    tailor-sdk tailordb migration generate
    ```
    This creates `migrations/0000/schema.json` from your current types.
-4. Run `tailor-sdk apply`. The migration label is set to `0000` on the deployed namespace.
+4. Run `tailor-sdk deploy`. The migration label is set to `0000` on the deployed namespace.
 
 ### Adding migrations to an existing project
 
@@ -53,7 +53,7 @@ If you already have a deployed workspace whose schema matches your local type de
 
 1. Add the `migration` block to `tailor.config.ts`.
 2. Run `tailor-sdk tailordb migration generate` to create `0000/schema.json` from current local types.
-3. Run `tailor-sdk apply`. Because remote schema already matches, no script runs; only the migration label is set.
+3. Run `tailor-sdk deploy`. Because remote schema already matches, no script runs; only the migration label is set.
 
 If your local types and remote schema have **diverged**, reconcile them before introducing migrations — either update local types to match remote, or accept that the first non-`0000` migration will reflect that gap.
 
@@ -109,7 +109,7 @@ A typical change cycle:
 
 4. **Apply.**
    ```bash
-   tailor-sdk apply
+   tailor-sdk deploy
    ```
    The pre-migration phase relaxes the new field to optional, the script runs and populates values, then the post-migration phase enforces `required: true`.
 
@@ -210,7 +210,7 @@ The same pattern works for switching between scalar and array.
 
 ## Automatic Migration Execution
 
-When you run `tailor-sdk apply`, the SDK detects pending migrations (anything past the current `sdk-migration` label on the deployed namespace) and runs them in order before continuing with the rest of the apply.
+When you run `tailor-sdk deploy`, the SDK detects pending migrations (anything past the current `sdk-migration` label on the deployed namespace) and runs them in order before continuing with the rest of the apply.
 
 ### Per-migration phases
 
@@ -243,7 +243,7 @@ Namespace: tailordb
 To bypass both checks (not recommended outside of recovery scenarios):
 
 ```bash
-tailor-sdk apply --no-schema-check
+tailor-sdk deploy --no-schema-check
 ```
 
 ### Example output
@@ -299,7 +299,7 @@ Migration numbers are assigned sequentially, so two developers branching off the
 
 1. Run `migration generate --init` to start over from `0000`.
 2. Run `tailor-sdk tailordb migration set 0` against the deployed namespace.
-3. Run `tailor-sdk apply` — the new `0000` becomes the baseline.
+3. Run `tailor-sdk deploy` — the new `0000` becomes the baseline.
 
 Coordinate this with your team because everyone else's local migrations will be invalidated.
 
@@ -315,7 +315,7 @@ After a failure:
 
 1. Read the `Logs:` block in the apply output to find the cause.
 2. Fix `migrate.ts` (or the data it depends on).
-3. Re-run `tailor-sdk apply`. The same migration runs again because its label was never bumped.
+3. Re-run `tailor-sdk deploy`. The same migration runs again because its label was never bumped.
 4. If the pre-migration relaxation is causing problems for application code in the meantime, accept the temporary optionality or roll forward with a fix; do not try to manually re-tighten the schema, or you'll create remote drift.
 
 If a migration **succeeds in script** but the post-migration phase fails (rare; usually due to constraint violation that the script should have prevented), the situation is the same as above plus the data changes from the script are persisted. Investigate, fix, and re-run.
@@ -345,7 +345,7 @@ The machine user needs read/write access to every type the migration script touc
 
 If you see `No machine user available for migration execution`, either:
 
-- Add `machineUsers: { ... }` to your auth config and `tailor-sdk apply` it, or
+- Add `machineUsers: { ... }` to your auth config and `tailor-sdk deploy` it, or
 - Set `migration.machineUser` to an existing machine user name in the db config.
 
 ## Multi-Namespace Coordination
@@ -409,7 +409,7 @@ For genuinely different schemas across environments, prefer separate workspaces
 
 **Cause:** Runtime error in your `migrate.ts`, a permission error from the machine user, or a constraint violation when post-migration tightens types.
 
-**Resolution:** Read the `Logs:` block. Fix the script or the data assumption it relies on, and re-run `tailor-sdk apply`. The label is not bumped on failure, so the same migration retries.
+**Resolution:** Read the `Logs:` block. Fix the script or the data assumption it relies on, and re-run `tailor-sdk deploy`. The label is not bumped on failure, so the same migration retries.
 
 ### `migrate.ts` not found for a migration that needs one
 

package/docs/services/tailordb.md

@@ -62,18 +62,19 @@ db.type("User", "User in the system", {
 
 ## Field Types
 
-| Method                          | TailorDB | TypeScript     |
-| ------------------------------- | -------- | -------------- |
-| `db.string()`                   | String   | string         |
-| `db.int()`                      | Integer  | number         |
-| `db.float()`                    | Float    | number         |
-| `db.bool()`                     | Boolean  | boolean        |
-| `db.date()`                     | Date     | string         |
-| `db.datetime()`                 | DateTime | string \| Date |
-| `db.time()`                     | Time     | string         |
-| `db.uuid()`                     | UUID     | string         |
-| [`db.enum()`](#enum-fields)     | Enum     | string         |
-| [`db.object()`](#object-fields) | Nested   | object         |
+| Method                            | TailorDB | TypeScript     |
+| --------------------------------- | -------- | -------------- |
+| `db.string()`                     | String   | string         |
+| `db.int()`                        | Integer  | number         |
+| `db.float()`                      | Float    | number         |
+| [`db.decimal()`](#decimal-fields) | Decimal  | string         |
+| `db.bool()`                       | Boolean  | boolean        |
+| `db.date()`                       | Date     | string         |
+| `db.datetime()`                   | DateTime | string \| Date |
+| `db.time()`                       | Time     | string         |
+| `db.uuid()`                       | UUID     | string         |
+| [`db.enum()`](#enum-fields)       | Enum     | string         |
+| [`db.object()`](#object-fields)   | Nested   | object         |
 
 ### Optional and Array Fields
 
@@ -83,6 +84,36 @@ db.string({ array: true });
 db.string({ optional: true, array: true });
 ```
 
+### Decimal Fields
+
+Decimal fields are stored as strings to preserve precision. The optional `scale`
+parameter sets the number of digits after the decimal point and must be an
+integer between 0 and 12. When `scale` is omitted, the platform default of 6 is
+used.
+
+```typescript
+// Default scale (6 decimal places)
+db.decimal();
+
+// Custom scale (2 decimal places)
+db.decimal({ scale: 2 });
+
+// Optional with custom scale
+db.decimal({ scale: 4, optional: true });
+```
+
+Values are rounded half-up to fit the configured scale before being stored.
+Negative values follow the same rule based on absolute magnitude:
+
+| Input         | Scale | Stored       |
+| ------------- | ----- | ------------ |
+| `"1.234"`     | 2     | `"1.23"`     |
+| `"1.235"`     | 2     | `"1.24"`     |
+| `"-1.235"`    | 2     | `"-1.24"`    |
+| `"1.5"`       | 0     | `"2"`        |
+| `"1.123456"`  | 6     | `"1.123456"` |
+| `"1.1234567"` | 6     | `"1.123457"` |
+
 ### Enum Fields
 
 ```typescript
@@ -589,6 +620,6 @@ db.type("User", {
 
 ## Migrations
 
-When you change a TailorDB type definition, the SDK can generate a migration that captures the diff and, for breaking changes, runs a data transformation script during `tailor-sdk apply`. See the [TailorDB Migrations guide](./tailordb-migration.md) for the full workflow, configuration, supported change types, team coordination, and troubleshooting.
+When you change a TailorDB type definition, the SDK can generate a migration that captures the diff and, for breaking changes, runs a data transformation script during `tailor-sdk deploy`. See the [TailorDB Migrations guide](./tailordb-migration.md) for the full workflow, configuration, supported change types, team coordination, and troubleshooting.
 
 For the CLI command reference, see [`tailordb migration`](../cli/tailordb.md#tailordb-migration).

package/docs/services/workflow.md

@@ -308,7 +308,7 @@ export default createResolver({
 });
 ```
 
-Wait points can be imported and used in any file (workflow jobs, resolvers, executors). For local testing, see [Testing Wait Points](../testing.md#testing-wait-points).
+Wait points can be imported and used in any file (workflow jobs, resolvers, executors). For local testing, see [Jobs that wait on approval](../testing.md#jobs-that-wait-on-approval) in the testing guide.
 
 ## Retry Policy