@tailor-platform/sdk 1.62.0 → 1.65.0

package/docs/github-actions.md

@@ -0,0 +1,337 @@
+# GitHub Actions Integration
+
+`tailor-sdk setup github` generates a GitHub Actions workflow that deploys your
+Tailor Platform application automatically on push or tag.
+
+> **Beta:** This command is under active development. CLI flags, the generated
+> workflow, and the `.github/tailor-sdk.lock` schema may change before general
+> availability.
+
+## Quick start
+
+Run the command from the root of your SDK project (where `tailor.config.ts`
+lives):
+
+```bash
+# Branch target: deploy to stg on every push to main
+tailor-sdk setup github -n my-app-stg
+
+# Tag target: deploy to production when a tag is pushed, with an approval gate
+tailor-sdk setup github -n my-app-prod \
+  --tag --branch main --environment production
+```
+
+After running the command, follow the **Next steps** printed to the terminal to
+set the required secrets, set the `TAILOR_PLATFORM_WORKSPACE_ID` variable, and
+commit the generated files.
+
+The generated workflow deploys to whichever workspace its
+`TAILOR_PLATFORM_WORKSPACE_ID` Environment variable points at — it never
+creates or renames a workspace. Provision the workspace and set that variable
+before the first deploy (see [Targeting a workspace](#targeting-a-workspace)).
+
+## Targets
+
+A _target_ is one workflow file that handles one deployment destination.
+Run `setup github` once per target.
+
+### Branch target (recommended for staging)
+
+The branch target fires on pull requests and pushes to the branch you specify
+(defaulting to the repository's default branch when `--branch` is omitted):
+
+```bash
+tailor-sdk setup github -n my-app-stg
+# Equivalent to:
+tailor-sdk setup github -n my-app-stg --branch main
+```
+
+What it does:
+
+- On **pull request**: runs `generate`, checks that generated files are
+  committed (`generate-check`), and posts a deployment plan as a PR comment.
+  (The plan and deploy jobs are independent; pull requests run plan only.)
+- On **push to the branch**: deploys. The deploy action runs `generate` and
+  applies the config; it does not re-run the PR plan.
+- On **`workflow_dispatch`** with `dry-run: true`: runs plan only (useful for
+  rollback verification — see [Rollback](#rollback)). With `dry-run: false`
+  (default) it deploys, like a push.
+
+Fork pull requests cannot read repository secrets. For forks, the plan step is
+automatically skipped; `generate-check` and other non-secret checks still run.
+
+### Tag target (recommended for production)
+
+The tag target fires when a tag matching `--tag-pattern` (default `v*`) is
+pushed:
+
+```bash
+tailor-sdk setup github -n my-app-prod \
+  --tag --tag-pattern "v*" --branch main --environment production
+```
+
+What it does:
+
+- **`tailor-tag-guard`** (generated when `--branch` is supplied): checks that
+  the tagged commit is reachable from `main`. A tag on an unrelated commit is
+  silently skipped, not an error.
+- **`tailor-plan`**: runs `generate`, `generate-check`, and posts a plan
+  summary to the Actions step summary (no PR comment, because there is no PR).
+- **`tailor-deploy`**: waits for `tailor-plan`, then deploys. If the target
+  environment has required reviewers configured, GitHub requires their approval
+  before the deploy job starts.
+- On **`workflow_dispatch`**: the `tailor-tag-guard` result is ignored — the
+  plan job runs regardless of branch reachability (useful for rolling back to
+  any tag). `dry-run: true` stops before the deploy job.
+
+### Choosing `--branch` for the tag target
+
+`--branch` has two different roles depending on the target kind:
+
+| Target | Role of `--branch`                                                                             |
+| ------ | ---------------------------------------------------------------------------------------------- |
+| Branch | The branch that triggers the workflow (push + PR base). Defaults to the repo's default branch. |
+| Tag    | The branch whose history the tag must be reachable from. Omit to disable the guard entirely.   |
+
+The workspace name (`--workspace-name`, or the config `name` when omitted) must
+be 3–63 characters of lowercase letters, numbers, and hyphens, and cannot start
+or end with a hyphen. It is used for the generated file name, the workflow
+`name:`, the plan label, and the default GitHub Environment name; it does not
+select which workspace gets deployed (see
+[Targeting a workspace](#targeting-a-workspace)).
+
+## Targeting a workspace
+
+The generated `plan` and `deploy` jobs target a workspace by **id**, read from
+the `TAILOR_PLATFORM_WORKSPACE_ID` GitHub Environment variable. They never
+resolve a workspace by name and never create one. Set this variable per
+environment before the first deploy.
+
+Because the variable is scoped to a GitHub Environment, both the `plan` and
+`deploy` jobs declare `environment:` so the value resolves. When you omit
+`--environment`, the environment name defaults to the workspace name.
+
+1. Provision the workspace (once per environment) and obtain its id. For now
+   this is a manual step:
+
+   ```bash
+   tailor-sdk workspace create   # copy the printed workspace id
+   ```
+
+2. Set the id as the Environment variable (the environment name is your
+   `--environment` value, or the workspace name when omitted):
+
+   ```bash
+   gh variable set TAILOR_PLATFORM_WORKSPACE_ID --env my-app-stg
+   ```
+
+If `TAILOR_PLATFORM_WORKSPACE_ID` is unset, `deploy` fails because the target
+workspace is not provisioned, and `plan` reports that the workspace is not
+provisioned yet instead of running a dry-run.
+
+If the target environment has required reviewers, that approval gate applies to
+the `plan` job as well as `deploy`, because `plan` must enter the environment to
+read the variable. (A token-based read that lets `plan` run without entering the
+environment is planned.)
+
+## Generated files
+
+Running `setup github` creates or updates:
+
+### `.github/workflows/tailor-<workspace-name>.yml`
+
+The workflow file. The `name:` field is set to `Tailor (<workspace-name>)` so
+you can distinguish multiple workspaces in the Actions UI.
+
+Jobs and steps whose `id` starts with `tailor-` are managed by the SDK. Do not
+edit or rename them — the SDK tracks them by id.
+
+You can add your own jobs and steps around the managed ones. To add
+project-specific setup (such as private registry authentication or a system
+dependency), add a step _before_ the managed setup steps. For post-install
+extras (such as `playwright install`), add a step _after_ them.
+
+Note that re-running `setup github` currently regenerates the whole file: if
+the file differs from what the SDK last wrote — whether you edited a managed
+step or added your own — the command stops and reports the conflict. Pass
+`--force` to discard your edits and regenerate from the current template, then
+re-apply your own steps. (Preserving user-added steps across regeneration is
+planned.)
+
+### `.github/tailor-sdk.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 github` injects one.
+This `id` must be committed alongside the workflow file. In CI, `tailor-sdk
+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.
+
+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_PLATFORM_SDK_ALLOW_CI_ID_INJECTION=true` to opt back
+into automatic id injection for that pipeline.
+
+## Secrets
+
+The generated workflow reads two secrets:
+
+| Secret                                       | Description                |
+| -------------------------------------------- | -------------------------- |
+| `TAILOR_PLATFORM_MACHINE_USER_CLIENT_ID`     | Machine user client ID     |
+| `TAILOR_PLATFORM_MACHINE_USER_CLIENT_SECRET` | Machine user client secret |
+
+Set them on the target GitHub Environment (the `--environment` value, or the
+workspace name when omitted) with the GitHub CLI:
+
+```bash
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_ID --env my-app-stg
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_SECRET --env my-app-stg
+```
+
+Setting them at the environment level isolates each target's credentials and
+keeps them alongside that environment's `TAILOR_PLATFORM_WORKSPACE_ID`
+variable. You can also set them as repository-level secrets if every target
+shares one machine user.
+
+## GitHub Environments (approval gate)
+
+Both the `plan` and `deploy` jobs are associated with a GitHub Environment — the
+`--environment` value, or the workspace name when omitted. The environment holds
+that target's `TAILOR_PLATFORM_WORKSPACE_ID` variable and machine-user secrets,
+and lets you:
+
+- **Require reviewer approval** before the jobs run (suitable for production).
+- **Scope secrets and the workspace-id variable** to specific environments so
+  staging and production deploy to separate workspaces with separate machine
+  users.
+
+To configure the environment, go to your repository's **Settings → Environments**
+and create an environment whose name matches the target's environment. Add
+required reviewers, the `TAILOR_PLATFORM_WORKSPACE_ID` variable, and the
+environment-scoped secrets there.
+
+Required reviewers gate the `plan` job as well, because `plan` must enter the
+environment to read `TAILOR_PLATFORM_WORKSPACE_ID`. (A token-based read that
+lets `plan` run without entering the environment is planned.)
+
+## Manual runs and dry-run
+
+You can trigger the workflow manually from **Actions → Run workflow**. The
+`dry-run` input (boolean, default `false`) runs the plan job without
+deploying. Use this to preview what would change before executing a rollback
+or an out-of-band deploy. With `dry-run` off, a branch-target dispatch goes
+straight to deploy (like a push), while a tag-target dispatch runs plan first
+and then deploys.
+
+For tag targets, you can select any branch or tag when dispatching manually. The tag-guard check is skipped for manual dispatches, so
+you can deploy any commit regardless of branch membership.
+
+## Monorepo setup
+
+For a monorepo where your SDK app lives in a subdirectory, pass `--dir`:
+
+```bash
+tailor-sdk setup github -n my-app --dir apps/backend
+```
+
+The generated workflow adds a `paths` filter on `apps/backend/**` so the
+workflow only runs when that subdirectory changes. The `working-directory` for
+SDK commands is set accordingly.
+
+## Rollback
+
+`tailor-sdk deploy` is declarative: redeploying a past configuration returns
+the platform to that state. The recommended rollback approaches are:
+
+### Option 1 — Revert the commit (branch target)
+
+```bash
+git revert <commit-sha>
+git push
+```
+
+The push triggers the deploy job, which applies the reverted configuration. To
+preview the diff first, open the revert as a pull request (the plan job comments
+the diff) or use a `dry-run: true` manual dispatch before merging.
+
+### Option 2 — Advance the tag (tag target)
+
+Move the production tag to an earlier commit:
+
+```bash
+git tag -f v1.2.3 <earlier-commit-sha>
+git push --force-with-lease origin v1.2.3
+```
+
+Or create a new tag that points to the earlier commit:
+
+```bash
+git tag v1.2.4 <earlier-commit-sha>
+git push origin v1.2.4
+```
+
+### Option 3 — Manual dispatch with dry-run verification
+
+1. Go to **Actions → `Tailor (<workspace-name>)` → Run workflow**.
+2. Enter the tag or ref you want to redeploy.
+3. Set `dry-run` to `true` and run. Inspect the plan output.
+4. Run again with `dry-run` set to `false`.
+
+For tag targets, the tag-guard step is bypassed on manual dispatch, so you can
+dispatch from any ref. Environment approval (if configured) applies as usual.
+
+### Rollback limitations
+
+- **Schema and data are not rolled back.** If the older config expects a schema
+  state that no longer exists, the plan may show errors. In that case, review
+  the diff carefully before proceeding.
+- **Seed data** is not part of the deployment pipeline and is unaffected by
+  rollbacks.
+- **Static websites** are not yet integrated into the generated pipeline.
+  Static asset rollbacks must be performed manually.
+
+## Multi-environment example
+
+A typical setup with staging and production:
+
+```bash
+# Staging: main → stg (deploy on every push to main)
+tailor-sdk setup github -n my-app-stg
+
+# Production: tagged commits → prod, with approval gate and branch guard
+tailor-sdk setup github -n my-app-prod \
+  --tag --branch main --environment production
+```
+
+Then provision each workspace and set its id on the matching environment (the
+staging target's environment defaults to `my-app-stg`; production uses
+`production`):
+
+```bash
+gh variable set TAILOR_PLATFORM_WORKSPACE_ID --env my-app-stg
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_ID --env my-app-stg
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_SECRET --env my-app-stg
+
+gh variable set TAILOR_PLATFORM_WORKSPACE_ID --env production
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_ID --env production
+gh secret set TAILOR_PLATFORM_MACHINE_USER_CLIENT_SECRET --env production
+```
+
+Commit both workflow files and `.github/tailor-sdk.lock`.
+
+## Updating the generated workflow
+
+When you upgrade the SDK, re-run `setup github` with the same flags to pick up
+template improvements. If the SDK detects that you have hand-edited a managed
+section, it stops and asks you to use `--force` to overwrite your edits, or to
+move your customizations into your own steps before regenerating.
+
+The `.github/tailor-sdk.lock` file records the flags used at generation time,
+so you can check what arguments were used previously.

package/docs/services/auth.md

@@ -515,6 +515,25 @@ export const auth = defineAuth("my-auth", {
 
 **invoker**: The machine user whose permissions are used to execute the hook. Must reference a machine user defined in the same auth configuration.
 
+### Federated identity claims
+
+When a user signs in through a Built-in IdP OAuth provider (Google or Microsoft), the upstream provider's profile is available on `claims.federated_identity`. It is `undefined` for password logins, so guard before reading it. Commonly present claims (`name`, `given_name`, `family_name`, `picture`, `locale`) are typed; any other claim the provider issues is forwarded as-is. Availability varies by provider (for example, Microsoft does not issue `picture`).
+
+```typescript
+hooks: {
+  beforeLogin: {
+    handler: async ({ claims }) => {
+      const federated = claims.federated_identity;
+      if (federated?.provider === "google") {
+        // Populate the user record from the upstream profile
+        const avatarUrl = federated.claims.picture;
+      }
+    },
+    invoker: "hook-invoker",
+  },
+}
+```
+
 ## CLI Commands
 
 Manage Auth resources using the CLI:

package/docs/services/idp.md

@@ -125,6 +125,89 @@ defineIdp("my-idp", {
 });
 ```
 
+### userAuthPolicy
+
+User authentication policy. Controls password requirements, the identifier used for login, allowed email domains, and social login providers. Every field is optional. The boolean options default to disabled, and the password length fields default to a minimum of 6 and a maximum of 4096.
+
+```typescript
+defineIdp("my-idp", {
+  clients: ["my-client"],
+  userAuthPolicy: {
+    useNonEmailIdentifier: false,
+    allowSelfPasswordReset: true,
+    passwordRequireUppercase: true,
+    passwordRequireLowercase: true,
+    passwordRequireNonAlphanumeric: true,
+    passwordRequireNumeric: true,
+    passwordMinLength: 8,
+    passwordMaxLength: 128,
+  },
+});
+```
+
+**Login behavior:**
+
+- `useNonEmailIdentifier` - Allow a non-email identifier (username) instead of requiring an email address. Default `false`.
+- `allowSelfPasswordReset` - Show the "Forgot password?" flow so users can reset their own password. Default `false`.
+- `disablePasswordAuth` - Remove password authentication entirely. Default `false`. Requires at least one social login provider to be enabled.
+
+**Password requirements:**
+
+- `passwordRequireUppercase` - Require at least one uppercase letter. Default `false`.
+- `passwordRequireLowercase` - Require at least one lowercase letter. Default `false`.
+- `passwordRequireNumeric` - Require at least one numeric character. Default `false`.
+- `passwordRequireNonAlphanumeric` - Require at least one non-alphanumeric character. Default `false`.
+- `passwordMinLength` - Minimum password length. Must be between 6 and 30. Default `6`.
+- `passwordMaxLength` - Maximum password length. Must be between 6 and 4096. Default `4096`.
+
+**Email domains and social login:**
+
+- `allowedEmailDomains` - Restrict registration to these email domains. An empty list (the default) allows all domains, but a non-empty list is required when `allowGoogleOauth` or `allowMicrosoftOauth` is enabled.
+- `allowGoogleOauth` - Enable the "Sign in with Google" button. Default `false`.
+- `allowMicrosoftOauth` - Enable the "Sign in with Microsoft" button. Default `false`.
+
+**Constraints:** the following combinations are rejected at parse time.
+
+- `passwordMinLength` must be less than or equal to `passwordMaxLength`.
+- A non-empty `allowedEmailDomains` cannot be combined with `useNonEmailIdentifier: true` (an empty list is allowed). Enabling `allowGoogleOauth` or `allowMicrosoftOauth` is likewise rejected with `useNonEmailIdentifier: true` (leaving them `false` or unset is fine).
+- `allowGoogleOauth` requires a non-empty `allowedEmailDomains`.
+- `allowMicrosoftOauth` requires both a non-empty `allowedEmailDomains` and `disablePasswordAuth: true`.
+- `disablePasswordAuth` requires `allowGoogleOauth` or `allowMicrosoftOauth`, and cannot be combined with `allowSelfPasswordReset`.
+
+### gqlOperations
+
+Controls which GraphQL user-management operations the IdP exposes. All operations are enabled by default. Use this to turn operations off entirely, independent of the `permission` policies that decide who may call them.
+
+```typescript
+defineIdp("my-idp", {
+  clients: ["my-client"],
+  gqlOperations: {
+    create: true,
+    read: true,
+    update: true,
+    delete: false,
+    sendPasswordResetEmail: false,
+  },
+});
+```
+
+**Fields:** each field defaults to `true` (enabled). Set a field to `false` to disable that operation.
+
+- `create` - The `_createUser` mutation.
+- `read` - The `_users` and `_user` query operations.
+- `update` - The `_updateUser` mutation.
+- `delete` - The `_deleteUser` mutation.
+- `sendPasswordResetEmail` - The `_sendPasswordResetEmail` mutation.
+
+**Shortcut:** pass the string `"query"` to expose a read-only IdP. It enables `read` and disables every mutation.
+
+```typescript
+defineIdp("my-idp", {
+  clients: ["my-client"],
+  gqlOperations: "query",
+});
+```
+
 ### authorization (optional, legacy)
 
 Legacy access control field. Use `permission` instead for fine-grained per-operation control. This field is kept for backward compatibility.
@@ -170,6 +253,19 @@ defineIdp("my-idp", {
 
 **Validation:** Each field must be 200 characters or less and must not contain newline characters.
 
+### lang
+
+UI language for the IdP-hosted pages such as the login and password reset screens.
+
+```typescript
+defineIdp("my-idp", {
+  clients: ["my-client"],
+  lang: "ja",
+});
+```
+
+**Values:** `"en"` or `"ja"`.
+
 ### publishUserEvents
 
 Publish IdP user lifecycle events (`idp.user.created`, `idp.user.updated`, `idp.user.deleted`). These events are consumed by executors that use `idpUserCreatedTrigger`, `idpUserUpdatedTrigger`, `idpUserDeletedTrigger`, or `idpUserTrigger`.

package/docs/services/tailordb-migration.md

@@ -355,20 +355,21 @@ Coordinate this with your team because everyone else's local migrations will be
 
 ## Failure Recovery
 
-If a `migrate.ts` throws:
+If the pre-migration phase or `migrate.ts` fails:
 
 - **The transaction rolls back** for that migration's script. Database changes the script made are undone.
-- **The pre-migration phase already ran** before the script. Type-level relaxations (e.g., a field changed to optional) **are not undone**. The post-migration phase, including the label bump, does not run.
-- The whole `apply` aborts. Subsequent migrations in the same run do not execute.
+- **The pre-migration schema changes are rolled back** to the prior checkpoint: types that already existed are restored to their previous shape, and types the migration newly introduced are dropped. The workspace is left at its prior checkpoint and prior schema — not half-applied.
+- The whole `apply` aborts and the checkpoint label is not bumped. Subsequent migrations in the same run do not execute.
+
+The rollback is best-effort per type; if reverting a type fails, a warning is logged and the original migration error is still reported.
 
 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 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.
+3. Re-run `tailor-sdk deploy`. The same migration runs again because its label was never bumped, and the prior-checkpoint schema is a clean baseline to retry against.
 
-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.
+If a migration **succeeds in script** but the **post-migration phase** fails (rare; usually a constraint violation the script should have prevented), the pre-migration changes are **not** rolled back: the script's data changes are already committed and the post-migration phase may have dropped removed columns or types, which cannot be reverted without data loss. Investigate, fix, and re-run.
 
 ## Rollback Strategy
 
@@ -444,6 +445,16 @@ For genuinely different schemas across environments, prefer separate workspaces
 4. To force the remote schema back to a known snapshot, use `migration sync <N>` (see [`migration sync` Semantics](#migration-sync-semantics)).
 5. As a last resort in non-production environments, `--no-schema-check` skips both checks. Do not use this as a routine workaround.
 
+### "Invalid schema snapshot" or "Invalid migration diff" error
+
+**Cause:** A `schema.json` or `diff.json` file in the `migrations/` directory is corrupted or does not match the expected structure. Merge conflicts left in these files are a common cause.
+
+**Resolution:**
+
+1. Read the error message — it includes the file path and the offending field.
+2. Restore the file from version control (`git checkout -- <path>`), or regenerate migration files with `migration generate` / `migration script`.
+3. Do not hand-edit `schema.json` or `diff.json`; they are managed by the CLI.
+
 ### "No machine user available for migration execution"
 
 **Cause:** Neither `migration.machineUser` is set nor are there any machine users in `auth.machineUsers`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "1.62.0",
+  "version": "1.65.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -146,11 +146,11 @@
     "@jridgewell/trace-mapping": "0.3.31",
     "@napi-rs/keyring": "1.3.0",
     "@opentelemetry/api": "1.9.1",
-    "@opentelemetry/exporter-trace-otlp-proto": "0.218.0",
-    "@opentelemetry/resources": "2.7.1",
-    "@opentelemetry/sdk-trace-node": "2.7.1",
+    "@opentelemetry/exporter-trace-otlp-proto": "0.219.0",
+    "@opentelemetry/resources": "2.8.0",
+    "@opentelemetry/sdk-trace-node": "2.8.0",
     "@opentelemetry/semantic-conventions": "1.41.1",
-    "@oxc-project/types": "0.134.0",
+    "@oxc-project/types": "0.135.0",
     "@standard-schema/spec": "1.1.0",
     "@tailor-platform/function-kysely-tailordb": "0.1.3",
     "@toiroakr/lines-db": "0.9.2",
@@ -169,34 +169,34 @@
     "madge": "8.0.0",
     "mime-types": "3.0.2",
     "open": "11.0.0",
-    "oxc-parser": "0.134.0",
+    "oxc-parser": "0.135.0",
     "p-limit": "7.3.0",
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.3.1",
     "politty": "0.5.1",
     "rolldown": "1.1.0",
-    "semver": "7.8.2",
+    "semver": "7.8.3",
     "sql-highlight": "6.1.0",
     "std-env": "4.1.0",
     "table": "6.9.0",
     "ts-cron-validator": "1.1.5",
     "tsx": "4.22.4",
     "type-fest": "5.7.0",
-    "undici": "8.4.0",
+    "undici": "8.4.1",
     "xdg-basedir": "5.1.0",
     "zod": "4.4.3"
   },
   "devDependencies": {
-    "@opentelemetry/sdk-trace-base": "2.7.1",
+    "@opentelemetry/sdk-trace-base": "2.8.0",
     "@types/madge": "5.0.3",
     "@types/mime-types": "3.0.1",
     "@types/node": "24.13.1",
     "@types/semver": "7.7.1",
-    "@typescript/native-preview": "7.0.0-dev.20260605.1",
+    "@typescript/native-preview": "7.0.0-dev.20260612.1",
     "@vitest/coverage-v8": "4.1.8",
-    "oxfmt": "0.53.0",
-    "oxlint": "1.68.0",
+    "oxfmt": "0.54.0",
+    "oxlint": "1.69.0",
     "oxlint-tsgolint": "0.23.0",
     "sonda": "0.11.1",
     "tsdown": "0.22.2",