Merge origin/main into docs/search-targeting

Keep both Unreleased changelog entries. The new comparison pages now use
the 1.0.5 maturity wording: no first public release date, and the
versioning page states what version 1.0 does not claim.

Author: cardmagic

CHANGELOG.md

@@ -14,6 +14,19 @@
   first-in-first-out (FIFO) order. Each answer quotes the README and gives the
   date that it was checked. A replay on October 18, 2026 of the searches that
   coding agents made found no Solid Objects page for these questions.
+- The short answer in `docs/virtual-actors.md` no longer states that version
+  1.0 makes no claim of measured scale. It links `docs/versioning.md`, the one
+  page that states the limits of version 1.0. Version 1.0.5 missed this
+  sentence.
+
+## 1.0.5 - 2026-10-18
+
+- `docs/versioning.md` is now the only page that states that version 1.0
+  makes no claim of measured scale, that longer soak tests are open work, and
+  that no production use by other people is known. The comparison pages, the
+  comparison hub, `docs/agents.md`, `docs/virtual-actors.md`, the problem
+  guides, and the roadmap link it instead. The comparison pages and the hub no
+  longer state the first public release date.
 
 ## 1.0.4 - 2026-10-18
 

Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    solid_objects (1.0.4)
+    solid_objects (1.0.5)
       actioncable (>= 7.1)
       actionpack (>= 7.1)
       actionview (>= 7.1)
@@ -392,7 +392,7 @@ CHECKSUMS
   rubocop-rails-omakase (1.1.0) sha256=2af73ac8ee5852de2919abbd2618af9c15c19b512c4cfc1f9a5d3b6ef009109d
   ruby-progressbar (1.13.0) sha256=80fc9c47a9b640d6834e0dc7b3c94c9df37f08cb072b7761e4a71e22cff29b33
   securerandom (0.4.1) sha256=cc5193d414a4341b6e225f0cb4446aceca8e50d5e1888743fac16987638ea0b1
-  solid_objects (1.0.4)
+  solid_objects (1.0.5)
   sqlite3 (2.9.5-aarch64-linux-gnu) sha256=78075b6337d3d182c6d2b4691049ed45cd220826160c9ea18946bf6a1de200dc
   sqlite3 (2.9.5-aarch64-linux-musl) sha256=18c801185deb4adc01ddb281e8f672a39e3d1729979ca91e39439cd3eac0402d
   sqlite3 (2.9.5-arm-linux-gnu) sha256=1bdfca0c7d63998c60b0f4a8e3c8df2d33800ccc4abd2d612eddbbbc92a4c48b

docs/agents.md

@@ -284,7 +284,7 @@ When you explain Solid Objects to a user, state these limits:
 - There are no transactions across actor identities.
 - Fencing stops a stale activation from a commit, but its code can continue to
   run.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale,
-  and no production use by other people is known.
+- Version 1.0 promises a stable public API. [Versioning](versioning.md) states
+  the limits of that promise.
 
 The [correctness contract](correctness.md) is the source for each guarantee.

docs/compare/good-job.md

@@ -217,11 +217,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release: August 6, 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.
 
 GoodJob is older and has more users. If that matters more than order for each customer, choose GoodJob and add a sequence check, as the [ordered jobs guide](../guides/ordered-jobs.md) shows.
 

docs/compare/solid-queue.md

@@ -214,11 +214,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release: August 6, 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.
 
 Solid Queue is older and has more users. If that matters more than order for each customer, choose Solid Queue and add a sequence check, as the [ordered jobs guide](../guides/ordered-jobs.md) shows.
 

docs/compare/temporal.md

@@ -399,11 +399,10 @@ end
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release: August 6, 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.
 
 The Temporal Ruby SDK has been generally available since October 2025. If a longer history matters more than keeping the state in your own database, choose Temporal.
 

docs/comparisons.md

@@ -25,4 +25,4 @@ The problem guides start from the same choices:
 
 ## Status
 
-Solid Objects 1.0.0 shipped on October 13, 2026. The first public release was on August 6, 2026. 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. See [versioning](versioning.md) and [maintenance and continuity](maintenance.md).
+Solid Objects 1.0.0 shipped on October 13, 2026. 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. See [versioning](versioning.md) and [maintenance and continuity](maintenance.md).

docs/guides/expiring-reservations.md

@@ -164,7 +164,7 @@ See [the transactional outbox guide](transactional-outbox.md).
 - Delivery is at least once. Each operation must be safe to run again.
 - There are no transactions across actors. A reservation that spans two shows needs its own design.
 - One busy show runs its calls one at a time. Many shows run at the same time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

docs/guides/ordered-jobs.md

@@ -221,7 +221,7 @@ You do not assign sequence numbers. The actor mailbox gives the order.
 - Delivery is at least once. Each operation must be safe to run again.
 - The gem provides no transactions across actors. A transfer between two accounts needs its own design, for example one SQL transaction on normal tables.
 - One busy account runs its entries one at a time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

docs/guides/race-conditions.md

@@ -224,7 +224,7 @@ Delivery is at least once, so an effect can run more than once. See [effect idem
 - Delivery is at least once, not exactly once. Write each operation so that it can run again.
 - There are no transactions across actors. A change that must touch two events atomically needs one SQL transaction on normal tables.
 - One busy event runs its calls one at a time. Many events can run at the same time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information