solid-objects 1.0.5 → 1.0.7

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.
@@ -381,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.
@@ -277,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.
@@ -272,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/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

@@ -65,19 +65,20 @@ as an instruction to divide the actor. See
 
 ## Runtime roles and supervision
 
-| Option                                      |         Default | Contract                                                          |
-| ------------------------------------------- | --------------: | ----------------------------------------------------------------- |
-| `workerCount`                               |             `1` | Non-negative actor workers.                                       |
-| `effectWorkerCount`                         |             `1` | Non-negative effect workers.                                      |
-| `broadcastWorkerCount`                      |             `1` | Non-negative broadcast workers when realtime is enabled.          |
-| `reminderSchedulerCount`                    |             `1` | Non-negative reminder schedulers.                                 |
-| `processHeartbeatIntervalMilliseconds`      |        `15_000` | Positive persisted heartbeat cadence.                             |
-| `processAliveThresholdMilliseconds`         |        `60_000` | Positive age after which an owner is stale.                       |
-| `shutdownTimeoutMilliseconds`               |        `15_000` | Positive shared graceful-shutdown budget.                         |
-| `supervisorRestartDelayMilliseconds`        |           `100` | Positive initial failed-role replacement delay.                   |
-| `supervisorMaximumRestartDelayMilliseconds` |        `10_000` | Positive cap no smaller than the initial delay.                   |
-| `wakeUp`                                    |   `"automatic"` | A name or an adapter implementing `watch`, `notify`, and `close`. |
-| `logger`                                    | console methods | Structured `debug`, `info`, `warn`, and `error` sink.             |
+| Option                                      |         Default | Contract                                                            |
+| ------------------------------------------- | --------------: | ------------------------------------------------------------------- |
+| `workerCount`                               |             `1` | Non-negative actor workers.                                         |
+| `effectWorkerCount`                         |             `1` | Non-negative effect workers.                                        |
+| `broadcastWorkerCount`                      |             `1` | Non-negative broadcast workers when realtime is enabled.            |
+| `reminderSchedulerCount`                    |             `1` | Non-negative reminder schedulers.                                   |
+| `processHeartbeatIntervalMilliseconds`      |        `15_000` | Positive persisted heartbeat cadence.                               |
+| `processAliveThresholdMilliseconds`         |        `60_000` | Positive age after which an owner is stale.                         |
+| `shutdownTimeoutMilliseconds`               |        `15_000` | Positive shared graceful-shutdown budget.                           |
+| `supervisorRestartDelayMilliseconds`        |           `100` | Positive initial failed-role replacement delay.                     |
+| `supervisorMaximumRestartDelayMilliseconds` |        `10_000` | Positive cap no smaller than the initial delay.                     |
+| `wakeUp`                                    |   `"automatic"` | A name or an adapter implementing `watch`, `notify`, and `close`.   |
+| `singleOwner`                               |         `false` | `true` when this process is the only writer of its SQLite database. |
+| `logger`                                    | console methods | Structured `debug`, `info`, `warn`, and `error` sink.               |
 
 Counts may be zero, but the complete configuration must leave at least one
 runtime role enabled. Broadcast workers are started only when `broadcast` or
@@ -90,7 +91,9 @@ Consecutive empty passes double it up to
 fixed cadence. A custom wake-up adapter must return `true` for a notification
 and `false` for a timeout. An older adapter that returns `void` remains
 compatible and keeps the fast cadence. Wake-ups reduce latency, while database
-polling remains the correctness path.
+polling remains the correctness path. The one exception is
+[`singleOwner`](#single-owner), which replaces polling with wake-ups and due
+times.
 
 Busy SQL workers and testing drains give the event loop a turn between passes.
 In Node this lets timers and input run even with synchronous SQLite calls.
@@ -98,6 +101,79 @@ An instrumentation callback can abort `runtime.run()` before its next pass.
 This does not interrupt a synchronous handler: responsiveness is bounded by
 one pass, or by a single overlong handler that must return first.
 
+## Single owner
+
+Set `singleOwner: true` when one process is the only writer of its SQLite
+database, for example a daemon that embeds the runtime and holds its database
+file. With the option, an idle runtime sends no query. The default is `false`,
+and the default behavior does not change.
+
+```typescript
+const runtime = createRuntime({
+  database: sqlite({ path: "app.sqlite" }),
+  singleOwner: true,
+})
+```
+
+With `singleOwner: true`, the runtime changes these behaviors:
+
+- Each role waits for an in-process wake-up or for the next due time that the
+  database reports. A due time is, for example, the time of the next ready
+  message, effect, broadcast, reminder, or retry, the end of a lease, or the
+  time when the owner of a claim becomes stale. A role with nothing due waits
+  up to 24 hours and then reads its due time again.
+- A write in this process that adds work or moves it earlier wakes the roles
+  that must react. A role that waits for a later due time then reads the new
+  due time.
+- The actor worker renews a lease only while it holds a cached activation.
+  When idle deactivation releases the last activation, the worker stops waking
+  for leases.
+- Each role writes its process row once at start and once at shutdown. A claim
+  also writes the row of the worker that claims, in the claim transaction, so
+  that running work always has a fresh owner. An empty pass writes nothing.
+- No periodic dead-process cleanup runs, and
+  `deadProcessCleanupIntervalMilliseconds` has no effect. `run()` releases
+  stale process rows once, at start.
+- A watch compares the wall clock with the process clock every 10 seconds.
+  Node timers stop while the computer sleeps, so after a sleep, or after a jump
+  of one second or more, every role reads its due time again. The watch sends
+  no query.
+- When a due time is now or has passed and a claim still finds nothing, the
+  role tries again after 1 ms. A timer can end a few milliseconds before the
+  database clock reaches the due time, and this retry takes the work at once.
+  Each further retry doubles the wait, up to the polling interval, so stuck
+  work cannot spin. `pollingIntervalMilliseconds` and
+  `idlePollingIntervalMilliseconds` set only this limit.
+
+Work that is active runs as before. A turn renews its lease, and an effect or a
+broadcast sends its process heartbeat while it runs. Automatic retention still
+runs at start and every `retentionIntervalMilliseconds`. Set that interval to
+`0` to stop it, and prune with `runtime.retention.prune()` instead.
+
+`run()` refuses to start with `SingleOwnerConflict` when another process row is
+alive by the usual rule: the row is not stopped, and its heartbeat is newer
+than `processAliveThresholdMilliseconds`. The error names each row and the time
+at which the row becomes stale. The rows of the runtime's own synchronous
+callers do not count.
+
+`createRuntime()` refuses the option in these cases:
+
+- The database is not SQLite. PostgreSQL and MySQL are servers that other
+  processes can reach. The runtime cannot know that it is the only writer, and
+  without polling a write from another process can wait up to 24 hours.
+- `wakeUp` is `"postgresql"`, `"redis"`, or an adapter. A notification over a
+  connection can be lost when the connection fails, and the runtime cannot
+  prove that a custom adapter delivers every signal. Without polling, a lost
+  signal can delay work for up to 24 hours. With `"automatic"` or
+  `"in_process"`, the runtime uses in-process signalling and ignores
+  `SOLID_OBJECTS_REDIS_URL`.
+
+Do not use the option with `sharedSqliteWasm`, because each tab runs its own
+runtime against the shared database. See
+[Correctness and delivery semantics](correctness.md#single-owner) for the
+guarantee and its limits, and [Operations](operations.md#single-owner) for
+monitoring.
+
 ## Retention and cleanup
 
 | Option                                   |           Default | Contract                                                         |
@@ -167,11 +243,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:
@@ -187,7 +282,8 @@ short capped backoff only when no synchronous deadline is active.
 
 `wakeUp` takes a name or an adapter, as `config.cache_store` does in Rails.
 `"automatic"` is the default. It prefers `SOLID_OBJECTS_REDIS_URL`, then
-PostgreSQL notifications, then polling. `"in_process"` opts out, `"postgresql"`
+PostgreSQL notifications, then polling. With `singleOwner`, the runtime runs no
+selection and uses in-process signalling. `"in_process"` opts out, `"postgresql"`
 and `"redis"` force one, and an unknown name throws rather than polls quietly.
 
 A requested adapter that the environment cannot provide polls instead and says

package/docs/correctness.md

@@ -36,9 +36,10 @@
 - Observable outbox rows are claimed in actor revision order. Subscription
   sessions and browser clients reject duplicate or stale revisions within an
   incarnation, while a recreated actor starts a new revision sequence.
-- Wake-up notifications happen only after commit and never replace polling.
-  Workers watch before claiming, so an in-process notification between an empty
-  claim and the following wait is retained.
+- Wake-up notifications happen only after commit and never replace polling,
+  except with [`singleOwner`](#single-owner). Workers watch before claiming, so
+  an in-process notification between an empty claim and the following wait is
+  retained.
 - Activation passes are bounded. Yielding changes ready-membership polling
   order only; it neither changes durable message sequence nor makes future work
   due early.
@@ -65,6 +66,56 @@
   delivery. A state change on an actor with payloads creates a revision
   broadcast, even when that actor declares no scalar observables.
 
+## Single owner
+
+With `singleOwner: true`, an idle runtime sends no query, and it still runs all
+work when the work arrives or comes due. This guarantee holds only while one
+process writes the database.
+
+The guarantee rests on these rules:
+
+- Every write that adds work or moves it earlier happens in this process. After
+  the commit, the write notifies an in-process signal for each role that must
+  react. A host that enqueues with
+  `runtime.enqueueInternalMessageInTransaction()` must call
+  `runtime.announceInternalMessage()` after its commit, as it must without the
+  option. Without that call, the message waits for the next wake-up.
+- A role watches the signal before it claims, so it cannot lose a notification
+  that arrives during a pass.
+- After an empty pass, a role reads the earliest time at which a claim can take
+  something. The read uses the same conditions as the claims: the head of each
+  mailbox, lease ends, pending effects, broadcasts, and reminders, claims whose
+  owners become stale, and recovery timeouts. The role waits until that time,
+  or for at most 24 hours.
+- A claim writes the row of the claiming worker in the claim transaction. A
+  worker that was idle for longer than `processAliveThresholdMilliseconds`
+  therefore never holds work under a stale row, and the alive rule protects
+  running work as it does without the option.
+
+Fencing and at-least-once delivery do not change. Claims, activation leases,
+the commit fence, retries, dead letters, and effect recovery use the same rows
+and the same conditions.
+
+The guarantee has these limits:
+
+- One process only. A write from another process, for example a second
+  runtime, a script, or a command, does not wake this runtime. That work waits
+  for the next local wake-up or due time, for at most 24 hours.
+- The start check reads the process rows once. It sees another writer only
+  while that writer's row is fresh, and an idle single owner does not refresh
+  its row. Two processes that start at the same moment can both pass the
+  check. Only an operating system lock, such as SQLite's exclusive locking
+  mode, keeps a second process out.
+- A due time runs on a Node timer. A long synchronous handler delays the timer,
+  as it delays polling. Node timers stop while the computer sleeps. A watch
+  sees the jump of the wall clock within 10 seconds and makes every role read
+  its due time again, so work that came due during a sleep runs at most about
+  10 seconds after the computer wakes.
+- When a due time is now or has passed and a claim still finds nothing, for
+  example after an actor setup failure, the role retries after 1 ms and then
+  doubles the wait up to its polling interval. Stuck work is then retried at
+  the polling interval, as it is without the option.
+
 ## Limitations and non-goals
 
 - At-least-once execution means actor code may begin more than once. State and
@@ -93,13 +144,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/errors-and-recovery.md

@@ -83,6 +83,10 @@ stable public code and does not classify the operation as failed.
   lookup found no record.
 - `ReminderNotPaused` means only a completed reminder remains; schedule it
   again through its actor instead of resuming it.
+- `SingleOwnerConflict` means a `singleOwner` runtime found another live
+  process row at start. Its `processes` list names each row and the time at
+  which the row becomes stale. Stop the other process, or wait until that time,
+  and start again.
 
 Realtime protocol validation uses `TypeError` for malformed subscription or
 browser envelopes. Server delivery failures are isolated to the session and

package/docs/operations.md

@@ -7,7 +7,8 @@ and work enqueued with `send` stays ready until some process runs the roles.
 A direct call or an explicit `sync` needs no running role, because the caller's
 own path executes it.
 
-Runtime roles use durable polling as the correctness fallback. Consecutive
+Runtime roles use durable polling as the correctness fallback, unless the
+runtime runs as a [single owner](#single-owner). Consecutive
 empty passes double each role's wait from `pollingIntervalMilliseconds` to
 `idlePollingIntervalMilliseconds`, which defaults to one second. Processed
 work and wake-up notifications reset the role to the fast interval. Actor
@@ -149,10 +150,10 @@ state from reconciliation code.
 The runtime automatically prunes expired message and stopped-process history
 once at startup and every `retentionIntervalMilliseconds`, which defaults to
 one hour. Stale process ownership is recovered independently every
-`deadProcessCleanupIntervalMilliseconds`, which defaults to one minute. Set an
-interval to zero to disable its scheduler. Failed passes emit metadata-only
-events and retry with bounded exponential backoff without stopping other
-runtime roles.
+`deadProcessCleanupIntervalMilliseconds`, which defaults to one minute. A
+single owner recovers it once, at start. Set an interval to zero to disable its
+scheduler. Failed passes emit metadata-only events and retry with bounded
+exponential backoff without stopping other runtime roles.
 
 Operators can also use `runtime.retention.preview()` and
 `runtime.retention.prune()`. Both calls require administration authorization;
@@ -228,6 +229,45 @@ Scheduling an existing actor operation for a different time emits
 `solid_objects.reminder.replaced` after the fenced actor commit. Scheduling it
 for the same time emits nothing.
 
+## Single owner
+
+With [`singleOwner: true`](configuration.md#single-owner), an idle runtime sends
+no query. Its roles wake for an in-process notification, for a due time that
+the database reports, or after the wall clock jumps. Expect these differences
+from the default:
+
+- `runtime.administration.processes()` reports the rows of an idle single owner
+  as `stale`, because a role writes its row only at start, at shutdown, and
+  when it claims work. The `runtime` doctor check can report no live roles for
+  the same reason. Both are normal while the runtime is idle.
+- The `wakeUp` doctor check passes with in-process signalling, because no other
+  process writes the database.
+- `cleanup()` can mark the rows of an idle single owner `stopped`. The next
+  claim of each role writes its row again. An idle role holds no claim, so the
+  cleanup releases nothing.
+- `currentPollingIntervalMilliseconds` and the
+  `solid_objects.polling.interval_changed` events describe only the retry of
+  due work that a claim cannot take.
+
+`run()` refuses to start with `SingleOwnerConflict` when another process row is
+alive. A process that stopped without cleanup stays alive until its heartbeat
+is older than `processAliveThresholdMilliseconds`. The error gives that time
+for each row. Stop the other process, or wait until that time, and start again.
+
+The start check reads the process rows once. It sees another writer only while
+that writer's row is fresh, and an idle single owner does not refresh its row.
+For a guarantee that the operating system enforces, take an exclusive lock on
+the file before the runtime writes to it:
+
+```typescript
+const database = sqlite({ path: "app.sqlite" })
+await database.connection((connection) => connection.run("PRAGMA locking_mode = EXCLUSIVE"))
+```
+
+SQLite then holds the lock from the first write until the database closes. A
+second process, including the `solid-objects` command for the same file, gets
+`database is locked`.
+
 ## Dead letters, retry, and redrive
 
 A handler failure that exhausts its attempts becomes a dead letter.

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "solid-objects",
-  "version": "1.0.5",
+  "version": "1.0.7",
   "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"