solid-objects 1.0.4 → 1.0.6

package/docs/compare/dbos.md

@@ -24,6 +24,16 @@ The DBOS facts come from the [DBOS documentation](https://docs.dbos.dev) and the
 
 Two DBOS pages differ on more than one process. The FAQ says "Conductor is required for correct workflow recovery in applications that use more than one process". The recovery page describes recovery without Conductor: each process has an executor ID, and a restarted process recovers its own pending workflows.
 
+## How do durable sleep, send, and recv work in DBOS?
+
+`DBOS.sleep` is a durable sleep inside a workflow. It takes milliseconds. DBOS "saves the wakeup time in the database so that even if the workflow is interrupted and restarted multiple times while sleeping, it still wakes up on schedule" ([DBOS workflow tutorial](https://docs.dbos.dev/typescript/tutorials/workflow-tutorial), checked October 18, 2026). `DBOS.send` sends a message to a workflow, and `DBOS.recv` in that workflow waits for it. "Messages are dequeued first-in, first-out from a queue associated with the topic" ([DBOS methods reference](https://docs.dbos.dev/typescript/reference/methods)).
+
+- `DBOS.recv` waits up to `timeoutSeconds` and then returns `null`. "The default timeout is 60 seconds" ([DBOS workflow communication](https://docs.dbos.dev/typescript/tutorials/workflow-communication)).
+- "If you're sending a message from a workflow, DBOS guarantees exactly-once delivery" ([DBOS workflow communication](https://docs.dbos.dev/typescript/tutorials/workflow-communication)).
+- With `delaySeconds` on enqueue, the workflow "is initially placed in `DELAYED` status and transitions to `ENQUEUED` after the delay expires" ([DBOS methods reference](https://docs.dbos.dev/typescript/reference/methods)).
+- A partitioned queue with `partitionConcurrency: 1` runs one workflow at a time for each `queuePartitionKey`.
+- In Solid Objects, a message to the actor replaces `send` and `recv`, and a reminder (`this.schedule({ at, key }).operation(input)`) replaces a durable sleep. Solid Objects has no durable wait inside a turn. The turn that stores the reminder ends, so other messages for the same cart run before the reminder runs.
+
 ## Choose DBOS when
 
 - The work is a sequence of steps, and a completed step must not run again after a crash.
@@ -351,11 +361,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release of the npm package: August 13, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 DBOS has a company, a hosted service, and a longer history. If those matter more than state for each cart, choose DBOS.
 
@@ -382,6 +391,8 @@ Checked October 15, 2026:
 - [DBOS upgrading workflows](https://docs.dbos.dev/typescript/tutorials/upgrading-workflows)
 - [Migrating from Temporal to DBOS](https://docs.dbos.dev/explanations/migrating-from-temporal)
 - [DBOS pricing](https://www.dbos.dev/dbos-pricing)
+- [DBOS methods reference](https://docs.dbos.dev/typescript/reference/methods) (checked October 18, 2026)
+- [DBOS workflow communication](https://docs.dbos.dev/typescript/tutorials/workflow-communication) (checked October 18, 2026)
 
 ## More information
 

package/docs/compare/graphile-worker.md

@@ -23,6 +23,16 @@ Solid Objects is an independent project. It is not affiliated with Graphile.
 
 The Graphile Worker facts come from the [Graphile Worker documentation](https://worker.graphile.org/docs) and its [source code](https://github.com/graphile/worker) (checked October 15, 2026).
 
+## Do jobs with the same `queue_name` run serially?
+
+Yes. Jobs in the same named queue run one at a time. The SQL function `graphile_worker.add_job` takes `queue_name`, and the JavaScript `addJob` takes `queueName`: "if you want certain tasks to run one at a time, add them to the same named queue" ([Graphile Worker `add_job`](https://worker.graphile.org/docs/sql-add-job), checked October 18, 2026).
+
+- The `TaskSpec` type describes `queueName` as "The queue to run this task under (only specify if you want jobs in this queue to run serially)" ([`addJob`](https://worker.graphile.org/docs/library/add-job)).
+- Serial is not the same as ordered after a failure. See the "Order after a failure" row above.
+- `job_key` (`jobKey` in JavaScript) is a "unique identifier for the job, used to replace, update or remove it later if needed" ([`add_job`](https://worker.graphile.org/docs/sql-add-job)). `job_key_mode` (`jobKeyMode` in JavaScript) is `replace` (the default), `preserve_run_at`, or `unsafe_dedupe` ([job keys](https://worker.graphile.org/docs/job-key)).
+- `run_at` (`runAt` in JavaScript) is "a timestamp after which to run the job; defaults to now".
+- In Solid Objects, the actor ID replaces `queue_name`, and `this.schedule({ at, key }).operation(input)` replaces `run_at` with a `job_key`.
+
 ## Choose Graphile Worker when
 
 - The work is background jobs, such as emails, webhooks, or reports.
@@ -256,11 +266,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release of the npm package: August 13, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 **Why Node.js 24.4 or newer?** The SQLite adapter reads integer columns as `BigInt`. Node.js 24.4.0 is the first release that accepts `readBigInts` on the built-in SQLite module. See [support](../support.md).
 
@@ -278,6 +287,7 @@ Checked October 15, 2026:
 
 - [Graphile Worker introduction](https://worker.graphile.org/docs)
 - [Graphile Worker `addJob`](https://worker.graphile.org/docs/library/add-job)
+- [Graphile Worker `add_job` in SQL](https://worker.graphile.org/docs/sql-add-job) (checked October 18, 2026)
 - [Graphile Worker job keys](https://worker.graphile.org/docs/job-key)
 - [Graphile Worker error handling](https://worker.graphile.org/docs/error-handling)
 - [Graphile Worker exponential backoff](https://worker.graphile.org/docs/exponential-backoff)

package/docs/compare/restate.md

@@ -20,6 +20,15 @@ Solid Objects is an independent project. It is not affiliated with Restate.
 
 The Restate facts come from the [Restate documentation](https://docs.restate.dev) and the [Restate server licence](https://github.com/restatedev/restate/blob/main/LICENSE) (checked October 15, 2026).
 
+## How do delayed messages and timers work in Restate?
+
+Restate names two ways to schedule work later in TypeScript. You can send a delayed message ([`restate.rpc.sendOpts({ delay })`](https://docs.restate.dev/develop/ts/service-communication)), or you can sleep (`ctx.sleep`) and then send a message. Restate recommends delayed messages, because "Other requests to the same Virtual Object can be processed during the delay period" ([Restate scheduling and timers](https://docs.restate.dev/develop/ts/durable-timers), checked October 18, 2026).
+
+- Restate "tracks and manages timers, ensuring they survive failures and restarts".
+- "If you sleep in an exclusive handler in a Virtual Object, all other calls to this object will be queued."
+- The SDK pages, the TypeScript pages included, call this a delayed message. Some operations pages, such as versioning and managing invocations, call it a delayed call.
+- In Solid Objects, `this.schedule({ at, key }).operation(input)` stores a reminder in the same SQL transaction as the turn. The turn ends at once, so other messages do not wait. One operation and key hold one alarm, and you can [cancel a reminder](../api.md#cancelling-a-reminder).
+
 ## Choose Restate when
 
 - You want a journal of each step, so that a retry resumes after the last completed step.
@@ -252,11 +261,10 @@ A model call can run again after a crash, because effects run at least once. If
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release of the npm package: August 13, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 Restate reached 1.0 in June 2024. If a longer history matters more than keeping the state in your own database, choose Restate.
 
@@ -273,13 +281,15 @@ Restate reached 1.0 in June 2024. If a longer history matters more than keeping
 Checked October 15, 2026:
 
 - [Restate services and virtual objects](https://docs.restate.dev/foundations/services)
-- [Restate service communication and delayed calls](https://docs.restate.dev/develop/ts/service-communication)
+- [Restate service communication and delayed messages](https://docs.restate.dev/develop/ts/service-communication)
 - [Restate durable steps](https://docs.restate.dev/develop/ts/durable-steps)
 - [Restate durable agents](https://docs.restate.dev/ai/patterns/durable-agents)
 - [Restate agent sessions](https://docs.restate.dev/ai/patterns/sessions)
 - [Restate sagas](https://docs.restate.dev/guides/sagas)
 - [Restate service configuration](https://docs.restate.dev/services/configuration)
 - [Restate server overview](https://docs.restate.dev/server/overview)
+- [Restate databases guide](https://docs.restate.dev/guides/databases)
+- [Restate scheduling and timers](https://docs.restate.dev/develop/ts/durable-timers) (checked October 18, 2026)
 - [Restate server licence](https://github.com/restatedev/restate/blob/main/LICENSE)
 
 ## More information

package/docs/compare/rivetkit.md

@@ -244,11 +244,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release of the npm package: August 13, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 **Why Node.js 24.4 or newer?** The SQLite adapter reads integer columns as `BigInt`. Node.js 24.4.0 is the first release that accepts `readBigInts` on the built-in SQLite module. See [support](../support.md).
 

package/docs/comparisons.md

@@ -15,6 +15,7 @@ runtime code on each page runs in the test suite.
 | [DBOS Transact and Solid Objects](compare/dbos.md)                           | Shopping cart checkout |
 | [RivetKit actors and Solid Objects](compare/rivetkit.md)                     | Chat rooms             |
 | [Graphile Worker named queues and Solid Objects](compare/graphile-worker.md) | Chat rooms             |
+| [Durable execution for TypeScript AI agents](compare/ai-agents.md)           | AI agent sessions      |
 
 ## Coordination models
 

package/docs/configuration.md

@@ -167,11 +167,30 @@ IDs, while PostgreSQL callers should use `RETURNING` with `get()`.
 
 ### SQLite
 
-`sqlite({ path, timeoutMilliseconds = 5_000, lockRetryAttempts = 10 })` uses
-Node's built-in `node:sqlite`. `lockRetryAttempts` is a positive integer. The
-timeout controls SQLite's busy timeout; transaction acquisition retries use
+`sqlite({ path, timeoutMilliseconds = 5_000, lockRetryAttempts = 10, synchronous = "normal" })`
+uses Node's built-in `node:sqlite`. `lockRetryAttempts` is a positive integer.
+The timeout controls SQLite's busy timeout; transaction acquisition retries use
 short capped backoff only when no synchronous deadline is active.
 
+A file database uses write-ahead logging (WAL). On its first access, the
+adapter sets `journal_mode = WAL` and the `synchronous` level, with the same
+retries as a transaction. WAL keeps two more files next to the database:
+`<path>-wal` and `<path>-shm`. Committed data can be in the `-wal` file, so a
+copy of the database file alone can miss it. To back up a database that is in
+use, run `VACUUM INTO '<backup path>'` or use the SQLite backup command. Copy
+the files only when no process has the database open. An in-memory database
+(`":memory:"`) keeps its memory journal.
+
+`synchronous` is `"normal"` or `"full"`:
+
+- `"normal"`, the default, is the level that the Ruby gem gets from Active
+  Record. A commit makes almost no `fsync` call. A process crash loses no
+  commit. A power loss or an operating system crash can lose the last commits,
+  but the database stays consistent.
+- `"full"` flushes each commit to disk before the commit returns. A commit
+  costs about one `fsync` call, and `node:sqlite` blocks the event loop while
+  it waits for the disk.
+
 ### PostgreSQL
 
 `postgresql(options)` accepts:

package/docs/correctness.md

@@ -93,13 +93,13 @@
   inside-transaction check) read as unset. Durable-state fencing, mailbox
   ordering, and the SQLite WASM deadline enforcement do not depend on those
   guards. The guards are best-effort in the browser and exact in Node.
-- `snapshotWithIncarnation`'s `createdAtMs` orders actor incarnations to the
-  millisecond. Every adapter stores `created_at_ms` at that same precision. If
-  you destroy and recreate the same actor identity inside one database-clock
-  millisecond, the two incarnations get an equal `createdAtMs`. In that narrow
-  case, a caller cannot tell which of the two is current, so it cannot fence a
-  derived write on that value. `instanceId` still changes and shows that a
-  recreation occurred. It is a random UUID and carries no order of its own.
+- `snapshotWithIncarnation` identifies a persisted incarnation by `instanceId`.
+  Use exact ID equality, with numeric revision comparison only within that ID.
+  `createdAtMs` is millisecond creation metadata; destruction and recreation can
+  produce equal timestamps and revisions while their IDs differ. Neither a
+  timestamp nor a random UUID provides a total incarnation order. Snapshot
+  reads alone do not atomically fence an external write; see
+  [Snapshot incarnation identity](api.md#snapshot-incarnation-identity).
 - Large documents, bulk pipelines, globally placed edge state, and global
   counters are outside the intended workload. Prefer an ordinary row
   transaction when it completely enforces the invariant.

package/docs/guides/persistent-rooms.md

@@ -383,7 +383,7 @@ The seventh test does not inject a late or repeated timer. The turn number check
 
 Delivery is at least once. Write each operation so that it can run again. One room runs one write at a time. This fits turn-based play, not a high-frequency game loop or fast real-time physics.
 
-The application owns the WebSocket server, authentication, and the display of the room. There are no transactions across two rooms. The package requires Node.js 24.4 or newer and ESM only. Version 1.0 promises a stable public API. It makes no claim of measured scale.
+The application owns the WebSocket server, authentication, and the display of the room. There are no transactions across two rooms. The package requires Node.js 24.4 or newer and ESM only. Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 See [Correctness and delivery semantics](../correctness.md) and [Virtual actors in TypeScript and Node.js](../virtual-actors.md).
 

package/docs/guides/race-conditions.md

@@ -355,7 +355,7 @@ There are no transactions across two actor identities. One identity runs one wri
 
 Each operation adds a message row. The runtime keeps completed messages for 30 days by default through `messageRetentionMilliseconds`. See [Configuration](../configuration.md#retention-and-cleanup) for retention and cleanup controls.
 
-The package requires Node.js 24.4 or newer and supports ESM only. Version 1.0 promises a stable public API. It makes no claim of measured scale. See [Correctness and delivery semantics](../correctness.md) and [Virtual actors in TypeScript and Node.js](../virtual-actors.md).
+The package requires Node.js 24.4 or newer and supports ESM only. Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise. See [Correctness and delivery semantics](../correctness.md) and [Virtual actors in TypeScript and Node.js](../virtual-actors.md).
 
 ## Sources
 

package/docs/parity.md

@@ -22,7 +22,10 @@ Ruby capabilities. Ruby's equivalent primitives
 (`SolidObjects::Mailbox#enqueue`, `ActorSnapshot`) are already reachable
 in-process, and they need no dedicated public API. Node's `exports` map enforces
 a package-privacy boundary between a package and its dependents. Ruby has no
-such boundary between a gem and its dependents.
+such boundary between a gem and its dependents. The TypeScript snapshot contract
+uses `instanceId` equality for incarnation identity and numeric revisions within
+that identity; creation timestamps are metadata and may tie. This clarifies the
+existing integration API without changing shared commit fencing or Ruby behavior.
 
 ## Status vocabulary
 
@@ -101,6 +104,7 @@ Ruby publishes RBS contracts with native Ruby field names; this does not change
 | Capability                  | Status | TypeScript shape or remaining work                                                                                                                                                                                                                                                                                                                                                    |
 | --------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | SQLite                      | Native | Uses built-in `node:sqlite`, serialized process-local access, bounded transient writer retries, foreign keys, strict tables, database time, and deadline-bounded access and lock waits. Ruby uses a yielding busy handler for background writes so a waiting thread lets the lock holder commit, including on Rails 7.1/7.2; both preserve synchronous deadlines.                     |
+| SQLite durability settings  | Native | File databases use WAL with synchronous NORMAL in both runtimes. Ruby gets them from Active Record; the Node adapter sets them on first access, and `synchronous: "full"` is optional.                                                                                                                                                                                                |
 | PostgreSQL                  | Native | Optional `pg` 8.23 peer, bounded pooling, 64-bit schema, row-locked sequences, server checks, and deadline-bounded pool, statement, and lock waits.                                                                                                                                                                                                                                   |
 | MySQL                       | Native | Optional `mysql2` 3.23 peer, bounded pooling, InnoDB schema, row-locked sequences, scoped deadlock retry, and deadline-bounded pool, query, and lock waits. Ruby also tests a second client, `trilogy`; Node has no comparable second MySQL client, so only `mysql2` is tracked here.                                                                                                 |
 | Durable polling fallback    | Native | Every role progresses without a notification service. Effects, reminders, and broadcasts use canonical ordered polling indexes; PostgreSQL and MySQL lock only the selected row with `FOR UPDATE SKIP LOCKED`. Broadcasts and reminders compare separate available and stale-recovery probes, preserve the oldest-first choice, and retry past candidates locked by another claimant. |
@@ -216,7 +220,8 @@ next section tracks it as a shared capability. All four milestones are
 complete:
 
 - M1: the shared modules no longer import Node built-in modules, a
-  registered platform factory supplies async context propagation, and
+  registered platform factory supplies Node async context and synchronous-only
+  browser context (guards are unset after `await`), and
   `pnpm run check` enforces a Node-free import graph for the browser-safe
   modules.
 - M2: `solid-objects/database/sqlite-wasm` implements the `Database`

package/docs/virtual-actors.md

@@ -12,8 +12,8 @@ no Cloudflare account, and no new datastore. A process of your application
 calls `runtime.run(signal)` to run reminders, effects, and queued messages.
 Redis is optional and only shortens wake-up latency.
 
-Solid Objects 1.0 promises a stable public API. It makes no claim of measured
-scale. Read
+Solid Objects 1.0 promises a stable public API. [Versioning](versioning.md)
+states the limits of that promise. Read
 [Compatibility and maturity](#compatibility-and-maturity) before you choose it.
 
 ## What a virtual actor is
@@ -246,10 +246,9 @@ These runtimes have different compatibility statements:
 | Browser runtime (`solid-objects/browser/host`)  | The actor runtime in a browser module worker on SQLite WASM. Tested in Chromium                                                                |
 | Cloudflare backend (`solid-objects/cloudflare`) | Experimental. It runs the actor API on Cloudflare Durable Objects, with different capability limits                                            |
 
-Version 1.0: the public API follows [semantic versioning](versioning.md). The
-Cloudflare backend is outside that promise. One first-party application with
-more than 100,000 users runs the package in production. That is a count of
-users, not a measure of load. The project makes no claim of measured scale,
-and no production use by other people is known.
+Version 1.0: the public API follows [semantic versioning](versioning.md),
+which also states the limits of that promise. The Cloudflare backend is outside
+that promise. One first-party application with more than 100,000 users runs the
+package in production. That is a count of users, not a measure of load.
 [Supported versions](support.md) lists the CI matrix. For Ruby on Rails, use
 the [solid_objects](https://github.com/cardmagic/solid-objects-ruby) gem.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "solid-objects",
-  "version": "1.0.4",
+  "version": "1.0.6",
   "description": "Fix race conditions across Node.js processes: ordered operations, expiring holds, and state that survives a restart, in your SQL database. A SQL-backed virtual actor library for TypeScript and Node.js.",
   "type": "module",
   "license": "MIT",
@@ -111,7 +111,7 @@
     "deploy:cloudflare": "wrangler deploy --config examples/cloudflare/wrangler.jsonc",
     "check:cloudflare": "node scripts/check-cloudflare-imports.mjs && tsc -p tsconfig.cloudflare-example.json --noEmit && wrangler deploy --dry-run --config examples/cloudflare/wrangler.jsonc",
     "build": "pnpm run clean && tsc -p tsconfig.build.json && tsc -p tsconfig.cloudflare-build.json && tsc -p tsconfig.quickstart-build.json && node scripts/prepare-executable.mjs",
-    "check": "pnpm run check:parameters && pnpm run check:documentation && pnpm run check:browser-imports && tsc -p tsconfig.json --noEmit && tsc -p tsconfig.examples.json --noEmit && tsc -p tsconfig.cloudflare.json --noEmit",
+    "check": "pnpm run check:parameters && pnpm run check:documentation && pnpm run check:browser-imports && tsc -p tsconfig.json --noEmit && tsc -p tsconfig.examples.json --noEmit && tsc -p tsconfig.cloudflare.json --noEmit && tsc -p tsconfig.benchmarks.json",
     "check:browser-imports": "node scripts/check-browser-imports.mjs",
     "check:documentation": "node scripts/check-documentation.mjs",
     "check:parameters": "node scripts/check-parameter-style.mjs",
@@ -121,8 +121,8 @@
     "test": "vitest run",
     "test:browser": "pnpm run build && playwright test",
     "test:coverage": "vitest run --coverage",
-    "test:postgresql": "vitest run test/postgresql.test.ts test/activation-lease.test.ts test/activation-recovery-backoff.test.ts test/caller-lifecycle.test.ts test/effect-recovery.test.ts test/instance-retention.test.ts test/transmit-ordering.test.ts",
-    "test:mysql": "vitest run test/mysql.test.ts test/activation-lease.test.ts test/activation-recovery-backoff.test.ts test/caller-lifecycle.test.ts test/effect-recovery.test.ts test/instance-retention.test.ts test/transmit-ordering.test.ts",
+    "test:postgresql": "vitest run test/postgresql.test.ts test/activation-lease.test.ts test/activation-recovery-backoff.test.ts test/caller-lifecycle.test.ts test/effect-recovery.test.ts test/instance-retention.test.ts test/transmit-ordering.test.ts test/snapshot-with-incarnation.test.ts",
+    "test:mysql": "vitest run test/mysql.test.ts test/activation-lease.test.ts test/activation-recovery-backoff.test.ts test/caller-lifecycle.test.ts test/effect-recovery.test.ts test/instance-retention.test.ts test/transmit-ordering.test.ts test/snapshot-with-incarnation.test.ts",
     "test:package": "node scripts/release-artifact-smoke.mjs",
     "test:recovery": "pnpm run build && node examples/failure-recovery/demo.ts",
     "test:at-least-once": "pnpm run build && node examples/at-least-once/demo.ts",
@@ -149,6 +149,7 @@
     "redis": "^6.2.1",
     "signal-polyfill": "^0.2.2",
     "typescript": "^5.9.0",
+    "vite": "^8.3.4",
     "vitest": "^4.1.11",
     "wrangler": "^4.129.0",
     "ws": "^8.21.3"