diff --git a/docs/deployment.md b/docs/deployment.md
index c7a0d0aeac0..b18a33fb11f 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -268,8 +268,63 @@ command-level Compose examples in the
 [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)
 section.
 
+### Upgrading to Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 adds one native-only table, `dw_run_command_contracts`. The
+native schema moves from 11 to 12 on MySQL, MariaDB and PostgreSQL, and from
+10 to 11 on SQLite. The upgrade creates the table and its index and rewrites
+no rows. Server 3.4.x has the same schema as 3.3.x, so this is the only schema
+step from 3.3.x or 3.4.x. A 3.5.0 Server started on the earlier schema refuses
+with `native_schema_upgrade_required`.
+
+For the single-node Compose deployment:
+
+1. Stop the Server and leave MySQL running:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Back up MySQL and `server_storage`, and record the current image
+   reference. This backup is the only way back to 3.4.x.
+3. Change `DW_SERVER_IMAGE` to the 3.5.0 image, pull it and run
+   `schema-upgrade` once:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   It prints the schema versions before and after, for example
+   `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Run
+   again on a current database, it reports `"status":"current"`.
+4. Start the Server with
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`,
+   then confirm `/api/ready`, `/api/cluster/info` (`version` is `3.5.0`) and
+   worker registration.
+
+On MySQL and MariaDB, an interrupted upgrade resumes when you run
+`schema-upgrade` again. Rolling back to 3.4.x needs the backup: a 3.4.x Server
+refuses the upgraded database with `native_schema_newer_than_binary`. From
+3.0.x through 3.2.x, the same command also applies the earlier steps described
+in the next section. The worker protocol stays at `1.20` and the control plane
+at version `2`.
+
+What changes for running workflows is in the
+[3.5.0 release notes](https://github.com/durable-workflow/server/releases/tag/3.5.0):
+updates for runs started before their worker registered now bind that worker's
+contract instead of being rejected, sticky execution with history suffixes,
+and expired runs pruned every minute by the maintenance loop.
+
 ### Upgrading from Server 3.0.x to 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+These are the earlier schema steps. If you go from 3.0.x straight to 3.5.0,
+use the 3.5.0 image in step 3; its `schema-upgrade` applies these steps and the
+3.5.0 step together, and the notes on PostgreSQL index builds and MySQL
+resumption below still apply.
+
 Server 3.3.2 crosses three minor releases from 3.0.x and changes the native
 schema. On MySQL, MariaDB and PostgreSQL it moves from version 8 (3.0.x and
 3.1.0) through 10 (3.2.0) to 11 (3.3.0 to 3.3.2). On SQLite it moves from 8
@@ -609,6 +664,17 @@ only when Helm's `lookup` shows every Server stopped. Argo CD, Flux and
 instead. A `helm rollback` to a chart 1.0.x revision does not bring the Server
 back, because 3.0.x refuses the upgraded database: restore the backup instead.
 
+Chart 1.2.0 moves the default image to Server 3.4.0 with no schema change, so
+a plain `helm upgrade` from chart 1.1.0 is enough. Native pods also gain a
+`preStop` sleep (`native.preStopSleepSeconds`, default 5) and a 70-second
+termination grace period. Chart 1.3.0 moves the default image to Server 3.5.0,
+which needs the [schema upgrade from 11 to 12](#native-schema-upgrade-3-5):
+scale the Server to zero, back up the database, and run `helm upgrade` with
+`native.schemaUpgrade.enabled=true` (or the manual Job), then scale back up.
+See the chart's
+[Chart 1.3.0 / Server 3.5.0 notes](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native).
+Going back to chart 1.2.0 means restoring that backup.
+
 ### Choosing a chart release {#helm-chart-selection}
 
 One chart release records the Server image it was tested against in `Chart.yaml`'s `appVersion`; the chart and Server have independent version numbers. The selected [compatibility tuple](./compatibility.md#last-qualified-reproducible-tuple) pairs chart **%%artifact.helmChartVersion%%** with Server **%%artifact.helmChartAppVersion%%**, from the same release metadata as the table and install command. Its [published OCI/package receipt](%%artifact.helmChartQualificationUrl%%) verifies that pairing, not a fresh Kubernetes installation.
diff --git a/docs/polyglot/server.md b/docs/polyglot/server.md
index cbe73f6e346..c37d297ec78 100644
--- a/docs/polyglot/server.md
+++ b/docs/polyglot/server.md
@@ -516,11 +516,11 @@ curl http://localhost:8080/api/cluster/info \
 
 Returns the build identity, capability flags, protocol manifests, limits and
 discovery for the namespace named by `X-Namespace` (or the `namespace` query
-parameter, else `default`). Abridged output from the 3.3.2 image:
+parameter, else `default`). Abridged output from the 3.5.0 image:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -561,6 +561,9 @@ parameter, else `default`). Abridged output from the 3.3.2 image:
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -586,11 +589,15 @@ Key field notes for client code:
 - The build version is `version`, not `server_version`. `implementation` is
   `"rust"` on the native Server.
 - Check `control_plane.version` and `worker_protocol.version` before calling
-  the API. Native 3.3.2 serves control plane `2` and worker protocol `1.20`,
+  the API. Native 3.5.0 serves control plane `2` and worker protocol `1.20`,
   and accepts worker requests that send any protocol version from `1.0` to
   `1.20`.
 - Workflow-task commands live under
   `worker_protocol.server_capabilities.supported_workflow_task_commands`.
+- Since 3.5.0, `worker_protocol.server_capabilities` advertises
+  `sticky_execution` and `sticky_history_suffix`. Since 3.4.0 it advertises
+  `activity_workflow_continuation`, which a worker uses only after its own
+  opt-in.
 - A capability flag set to `false` names a feature or published contract that
   native does not serve. `response_compression` is empty because native sends
   uncompressed responses.
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
index 925079282a0..f2e6ef55d98 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
@@ -195,8 +195,39 @@ Upgrade-Reihenfolge:
 
 Der native Server prüft sein Schema beim Start. Patch-Veröffentlichungen innerhalb einer nativen Minor-Linie behalten das Schema bei, daher genügt ein Image-Wechsel. Eine Veröffentlichung, deren Hinweise eine Schemaänderung ankündigen, benötigt zusätzlich den Befehl `schema-upgrade` des Images, ausgeführt nach einer Datenbanksicherung, während alle Server gestoppt sind. Die Server-Referenz enthält aktuelle Compose-Befehlsbeispiele unter [Offizielles Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Upgrade auf Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 fügt eine nur native Tabelle hinzu, `dw_run_command_contracts`. Das native Schema wechselt auf MySQL, MariaDB und PostgreSQL von 11 auf 12 und auf SQLite von 10 auf 11. Das Upgrade legt die Tabelle und ihren Index an und schreibt keine Zeilen um. Server 3.4.x hat dasselbe Schema wie 3.3.x, daher ist dies von 3.3.x oder 3.4.x aus der einzige Schemaschritt. Ein Server 3.5.0, der auf dem früheren Schema gestartet wird, verweigert den Start mit `native_schema_upgrade_required`.
+
+Für die Compose-Bereitstellung auf einem einzelnen Knoten:
+
+1. Stoppen Sie den Server und lassen Sie MySQL weiterlaufen:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Sichern Sie MySQL und `server_storage` und halten Sie die aktuelle Image-Referenz fest. Diese Sicherung ist der einzige Weg zurück zu 3.4.x.
+3. Ändern Sie `DW_SERVER_IMAGE` auf das 3.5.0-Image, rufen Sie es ab und führen Sie `schema-upgrade` einmal aus:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   Der Befehl gibt die Schemaversionen vorher und nachher aus, zum Beispiel `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Erneut auf einer aktuellen Datenbank ausgeführt, meldet er `"status":"current"`.
+4. Starten Sie den Server mit `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` und bestätigen Sie dann `/api/ready`, `/api/cluster/info` (`version` ist `3.5.0`) und die Worker-Registrierung.
+
+Auf MySQL und MariaDB wird ein unterbrochenes Upgrade fortgesetzt, wenn Sie `schema-upgrade` erneut ausführen. Ein Rollback auf 3.4.x erfordert die Sicherung: Ein 3.4.x-Server verweigert die aktualisierte Datenbank mit `native_schema_newer_than_binary`. Von 3.0.x bis 3.2.x wendet derselbe Befehl auch die früheren Schritte aus dem nächsten Abschnitt an. Das Worker-Protokoll bleibt bei `1.20` und die Steuerungsebene bei Version `2`.
+
+Was sich für laufende Workflows ändert, steht in den [Versionshinweisen zu 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0): Updates für Ausführungen, die gestartet wurden, bevor ihr Worker sich registriert hat, binden jetzt den Vertrag dieses Workers, statt abgelehnt zu werden; Sticky Execution mit History-Suffixen; und abgelaufene Ausführungen werden von der Wartungsschleife jede Minute bereinigt.
+
 ### Upgrade von Server 3.0.x auf 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Dies sind die früheren Schemaschritte. Wenn Sie von 3.0.x direkt auf 3.5.0 wechseln, verwenden Sie in Schritt 3 das 3.5.0-Image. Sein `schema-upgrade` wendet diese Schritte und den Schritt für 3.5.0 gemeinsam an, und die Hinweise unten zu PostgreSQL-Indexaufbau und Fortsetzung auf MySQL gelten weiterhin.
+
 Server 3.3.2 liegt drei Minor-Veröffentlichungen nach 3.0.x und ändert das native Schema. Auf MySQL, MariaDB und PostgreSQL wechselt es von Version 8 (3.0.x und 3.1.0) über 10 (3.2.0) auf 11 (3.3.0 bis 3.3.2). Auf SQLite wechselt es von 8 auf 10. Ein Server aktualisiert sein Schema nie beim Start: 3.3.2 verweigert auf einer Datenbank mit Version 8 den Start mit `native_schema_upgrade_required`, daher kann der neue Server nicht starten, wenn nur `DW_SERVER_IMAGE` geändert wird. Der Befehl `schema-upgrade` des 3.3.2-Images aktualisiert eine Datenbank mit Version 8 direkt. Die [Upgrade-Hinweise zu 3.3.0](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade) beschreiben den Schritt, und die [Hinweise zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Helm-Charts führen die Schemaschritte und die Laufzeitänderungen von 3.0.5 auf 3.3.2 auf.
 
 Für die Compose-Bereitstellung auf einem einzelnen Knoten:
@@ -438,6 +469,8 @@ Ein bestehender PHP-2.x-Release wechselt bei einem gewöhnlichen Upgrade nicht a
 
 Chart 1.1.0 ändert das Standard-Image von Server 3.0.5 auf 3.3.2, das das [native Schema-Upgrade](#native-schema-upgrade-3-0-to-3-3) von 8 auf 11 erfordert. Ein gewöhnliches `helm upgrade` von Chart 1.0.x ändert nur das Image, und die neuen Pods verweigern den Start mit `native_schema_upgrade_required`. Folgen Sie den [Schritten zu Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) des Charts: Skalieren Sie den Server bei ausgeschaltetem Autoscaling auf null, sichern Sie die Datenbank und führen Sie dann das Upgrade auf Chart 1.1.0 mit `native.schemaUpgrade.enabled=true` aus. Sein `pre-upgrade`-Hook führt `schema-upgrade` einmal aus, bevor die neuen Pods starten, und nur, wenn Helms `lookup` zeigt, dass alle Server gestoppt sind. Renderings durch Argo CD, Flux und `helm template` verweigern den Hook; verwenden Sie stattdessen den manuellen Job aus der README des Charts. Ein `helm rollback` auf eine Revision von Chart 1.0.x bringt den Server nicht zurück, weil 3.0.x die aktualisierte Datenbank verweigert: Stellen Sie stattdessen die Sicherung wieder her.
 
+Chart 1.2.0 setzt das Standard-Image ohne Schemaänderung auf Server 3.4.0, daher genügt von Chart 1.1.0 aus ein einfaches `helm upgrade`. Native Pods erhalten außerdem eine `preStop`-Pause (`native.preStopSleepSeconds`, Standard 5) und eine Beendigungsfrist von 70 Sekunden. Chart 1.3.0 setzt das Standard-Image auf Server 3.5.0, das das [Schema-Upgrade von 11 auf 12](#native-schema-upgrade-3-5) benötigt: Skalieren Sie den Server auf null, sichern Sie die Datenbank und führen Sie `helm upgrade` mit `native.schemaUpgrade.enabled=true` aus (oder den manuellen Job), skalieren Sie danach wieder hoch. Siehe die [Hinweise zu Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) des Charts. Zurück zu Chart 1.2.0 geht es nur über diese Sicherung.
+
 ### Einen Chart-Release auswählen {#helm-chart-selection}
 
 Jeder Chart-Release hält das getestete Server-Image in der `appVersion` der `Chart.yaml` fest; Chart und Server haben unabhängige Versionsnummern. Die ausgewählte [kompatible Kombination](./compatibility.md#last-qualified-reproducible-tuple) verbindet Chart **%%artifact.helmChartVersion%%** mit Server **%%artifact.helmChartAppVersion%%** aus denselben Release-Metadaten wie Tabelle und Installationsbefehl. Der [Prüfbericht zu OCI/veröffentlichtem Paket](%%artifact.helmChartQualificationUrl%%) bestätigt diese Kombination, keine neue Kubernetes-Installation.
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md
index c9dde783bad..9febd61ef7c 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -412,11 +412,11 @@ curl http://localhost:8080/api/cluster/info \
 
 Liefert Build-Identität, Fähigkeitsflags, Protokollmanifeste, Limits und
 Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter
-`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.3.2:
+`namespace`, sonst `default`). Gekürzte Ausgabe des Images 3.5.0:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -457,6 +457,9 @@ Erkennungsdaten für den Namespace aus `X-Namespace` (oder dem Abfrageparameter
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -482,11 +485,12 @@ Wichtige Feldhinweise für Client-Code:
 - Die Build-Version steht in `version`, nicht in `server_version`.
   `implementation` ist auf dem nativen Server `"rust"`.
 - Prüfen Sie `control_plane.version` und `worker_protocol.version`, bevor Sie die
-  API aufrufen. Der native Server 3.3.2 bedient Steuerungsebene `2` und Worker-Protokoll
+  API aufrufen. Der native Server 3.5.0 bedient Steuerungsebene `2` und Worker-Protokoll
   `1.20` und akzeptiert Worker-Anfragen mit jeder Protokollversion von `1.0` bis
   `1.20`.
 - Workflow-Aufgabenbefehle stehen unter
   `worker_protocol.server_capabilities.supported_workflow_task_commands`.
+- Seit 3.5.0 meldet `worker_protocol.server_capabilities` `sticky_execution` und `sticky_history_suffix`. Seit 3.4.0 meldet es `activity_workflow_continuation`, das ein Worker nur nach seinem eigenen Opt-in verwendet.
 - Ein auf `false` gesetztes Fähigkeitsflag benennt eine Funktion oder einen
   veröffentlichten Vertrag, den der native Server nicht bedient.
   `response_compression` ist leer, weil der native Server Antworten
diff --git a/i18n/de/source-hashes.json b/i18n/de/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/de/source-hashes.json
+++ b/i18n/de/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/deployment.md b/i18n/es/docusaurus-plugin-content-docs/current/deployment.md
index 8fd2b290e73..e2db0c48312 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/deployment.md
@@ -263,8 +263,44 @@ la base de datos y con todos los Server detenidos. La referencia de Server
 mantiene los comandos Compose actualizados en
 [Imagen oficial + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Actualizar a Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 añade una tabla exclusiva de native, `dw_run_command_contracts`. El esquema native pasa de 11 a 12 en MySQL, MariaDB y PostgreSQL, y de 10 a 11 en SQLite. La actualización crea la tabla y su índice y no reescribe ninguna fila. Server 3.4.x tiene el mismo esquema que 3.3.x, así que este es el único paso de esquema desde 3.3.x o 3.4.x. Un Server 3.5.0 iniciado sobre el esquema anterior se niega a arrancar con `native_schema_upgrade_required`.
+
+Para el despliegue Compose de un solo nodo:
+
+1. Detén el Server y deja MySQL en ejecución:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Haz copia de MySQL y de `server_storage`, y registra la referencia de la
+   imagen actual. Esta copia es la única forma de volver a 3.4.x.
+3. Cambia `DW_SERVER_IMAGE` a la imagen 3.5.0, descárgala y ejecuta
+   `schema-upgrade` una vez:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   Muestra las versiones de esquema antes y después, por ejemplo `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Si se ejecuta de nuevo sobre una base de datos actual, informa `"status":"current"`.
+4. Inicia el Server con
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`
+   y después confirma `/api/ready`, `/api/cluster/info` (`version` es `3.5.0`) y
+   el registro de workers.
+
+En MySQL y MariaDB, una actualización interrumpida se reanuda al volver a ejecutar `schema-upgrade`. Volver a 3.4.x requiere la copia de seguridad: un Server 3.4.x rechaza la base de datos actualizada con `native_schema_newer_than_binary`. Desde 3.0.x hasta 3.2.x, el mismo comando también aplica los pasos anteriores que describe la sección siguiente. El protocolo de workers se mantiene en `1.20` y el plano de control en la versión `2`.
+
+Lo que cambia para los workflows en ejecución está en las [notas de la versión 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0): las actualizaciones de ejecuciones iniciadas antes de que su worker se registrara ahora vinculan el contrato de ese worker en lugar de rechazarse, ejecución sticky con sufijos de historial, y el bucle de mantenimiento elimina cada minuto las ejecuciones vencidas.
+
 ### Actualizar de Server 3.0.x a 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Estos son los pasos de esquema anteriores. Si pasa de 3.0.x directamente a 3.5.0, use la imagen 3.5.0 en el paso 3: su `schema-upgrade` aplica estos pasos y el de 3.5.0 a la vez, y las notas siguientes sobre la creación de índices en PostgreSQL y la reanudación en MySQL siguen vigentes.
+
 Server 3.3.2 atraviesa tres versiones menores desde 3.0.x y cambia el esquema
 nativo. En MySQL, MariaDB y PostgreSQL pasa de la versión 8 (3.0.x y 3.1.0)
 por la 10 (3.2.0) hasta la 11 (de 3.3.0 a 3.3.2). En SQLite pasa de la 8 a la
@@ -579,6 +615,8 @@ Una versión PHP 2.x existente no pasa al Server nativo con una actualización o
 
 El chart 1.1.0 cambia la imagen predeterminada de Server 3.0.5 a 3.3.2, que necesita la [actualización del esquema nativo](#native-schema-upgrade-3-0-to-3-3) de 8 a 11. Un `helm upgrade` ordinario desde el chart 1.0.x solo cambia la imagen, y los pods nuevos se niegan a arrancar con `native_schema_upgrade_required`. Siga los [pasos de Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) del chart: escale el Server a cero con el autoescalado desactivado, haga una copia de seguridad de la base de datos y después actualice al chart 1.1.0 con `native.schemaUpgrade.enabled=true`. Su hook `pre-upgrade` ejecuta `schema-upgrade` una vez antes de que arranquen los pods nuevos, y solo cuando el `lookup` de Helm muestra todos los Server detenidos. Los manifiestos generados por Argo CD, Flux y `helm template` rechazan el hook; use en su lugar el Job manual del README del chart. Un `helm rollback` a una revisión del chart 1.0.x no recupera el Server, porque 3.0.x rechaza la base de datos actualizada: restaure la copia de seguridad en su lugar.
 
+El chart 1.2.0 cambia la imagen predeterminada a Server 3.4.0 sin cambio de esquema, así que desde el chart 1.1.0 basta con un `helm upgrade` normal. Los pods native también incorporan una pausa `preStop` (`native.preStopSleepSeconds`, 5 por defecto) y un periodo de gracia de terminación de 70 segundos. El chart 1.3.0 cambia la imagen predeterminada a Server 3.5.0, que necesita la [actualización de esquema de 11 a 12](#native-schema-upgrade-3-5): escale el Server a cero, haga una copia de seguridad de la base de datos y ejecute `helm upgrade` con `native.schemaUpgrade.enabled=true` (o el Job manual), y luego vuelva a escalar. Consulte las [notas de Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) del chart. Volver al chart 1.2.0 implica restaurar esa copia.
+
 ### Elegir una versión del chart {#helm-chart-selection}
 
 Cada versión del chart registra en `appVersion` de `Chart.yaml` la imagen del Server con la que se probó; el chart y el Server tienen números de versión independientes. La [combinación compatible seleccionada](./compatibility.md#last-qualified-reproducible-tuple) empareja el chart **%%artifact.helmChartVersion%%** con Server **%%artifact.helmChartAppVersion%%**, usando los mismos metadatos de versiones que la tabla y el comando de instalación. La [verificación OCI/del paquete publicado](%%artifact.helmChartQualificationUrl%%) comprueba ese par, no una instalación nueva de Kubernetes.
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md
index 68d3c892bd8..3225fc24633 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -377,11 +377,11 @@ curl http://localhost:8080/api/cluster/info \
   -H "Authorization: Bearer $TOKEN"
 ```
 
-Devuelve la identidad de la compilación, los indicadores de capacidad, los manifiestos de protocolo, los límites y el descubrimiento del namespace indicado por `X-Namespace` (o por el parámetro de consulta `namespace`; si no, `default`). Salida abreviada de la imagen 3.3.2:
+Devuelve la identidad de la compilación, los indicadores de capacidad, los manifiestos de protocolo, los límites y el descubrimiento del namespace indicado por `X-Namespace` (o por el parámetro de consulta `namespace`; si no, `default`). Salida abreviada de la imagen 3.5.0:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -422,6 +422,9 @@ Devuelve la identidad de la compilación, los indicadores de capacidad, los mani
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -445,7 +448,8 @@ Devuelve la identidad de la compilación, los indicadores de capacidad, los mani
 Notas sobre los campos clave para el código cliente:
 
 - La versión de la compilación es `version`, no `server_version`. `implementation` es `"rust"` en el Server nativo.
-- Compruebe `control_plane.version` y `worker_protocol.version` antes de llamar a la API. El Server nativo 3.3.2 sirve el plano de control `2` y el protocolo de workers `1.20`, y acepta solicitudes de workers que envíen cualquier versión de protocolo desde `1.0` hasta `1.20`.
+- Compruebe `control_plane.version` y `worker_protocol.version` antes de llamar a la API. El Server nativo 3.5.0 sirve el plano de control `2` y el protocolo de workers `1.20`, y acepta solicitudes de workers que envíen cualquier versión de protocolo desde `1.0` hasta `1.20`.
+- Desde 3.5.0, `worker_protocol.server_capabilities` anuncia `sticky_execution` y `sticky_history_suffix`. Desde 3.4.0 anuncia `activity_workflow_continuation`, que un worker solo usa tras activarlo explícitamente.
 - Los comandos de tareas de workflow están en `worker_protocol.server_capabilities.supported_workflow_task_commands`.
 - Un indicador de capacidad con valor `false` designa una función o un contrato publicado que el Server nativo no sirve. `response_compression` está vacío porque el Server nativo envía respuestas sin comprimir.
 - `native_unqualified` enumera cada miembro de la respuesta de PHP 2.x que el Server nativo omite, junto con el motivo. Incluye `topology`.
diff --git a/i18n/es/source-hashes.json b/i18n/es/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/es/source-hashes.json
+++ b/i18n/es/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md b/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md
index 056c90974a8..c8d8b9c7f26 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md
@@ -269,8 +269,44 @@ pendant que tous les Servers sont arrêtés. La référence Server conserve les
 exemples Compose actuels au niveau des commandes dans la section
 [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Mettre à niveau vers Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 ajoute une table propre à native, `dw_run_command_contracts`. Le schéma native passe de 11 à 12 sur MySQL, MariaDB et PostgreSQL, et de 10 à 11 sur SQLite. La mise à niveau crée la table et son index et ne réécrit aucune ligne. Server 3.4.x a le même schéma que 3.3.x : c'est donc la seule étape de schéma depuis 3.3.x ou 3.4.x. Un Server 3.5.0 démarré sur l'ancien schéma refuse de démarrer avec `native_schema_upgrade_required`.
+
+Pour le déploiement Compose sur un nœud :
+
+1. Arrêtez le Server et laissez MySQL en marche :
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Sauvegardez MySQL et `server_storage`, et consignez la référence de l'image
+   actuelle. Cette sauvegarde est le seul moyen de revenir à 3.4.x.
+3. Remplacez `DW_SERVER_IMAGE` par l'image 3.5.0, téléchargez-la et exécutez
+   `schema-upgrade` une fois :
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   La commande affiche les versions de schéma avant et après, par exemple `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Relancée sur une base déjà à jour, elle indique `"status":"current"`.
+4. Démarrez le Server avec
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`,
+   puis confirmez `/api/ready`, `/api/cluster/info` (`version` vaut `3.5.0`) et
+   l'enregistrement worker.
+
+Sur MySQL et MariaDB, une mise à niveau interrompue reprend quand vous relancez `schema-upgrade`. Revenir à 3.4.x exige la sauvegarde : un Server 3.4.x refuse la base mise à niveau avec `native_schema_newer_than_binary`. De 3.0.x à 3.2.x, la même commande applique aussi les étapes antérieures décrites dans la section suivante. Le protocole des workers reste en `1.20` et le plan de contrôle en version `2`.
+
+Ce qui change pour les workflows en cours figure dans les [notes de version 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0) : les mises à jour des exécutions démarrées avant l'enregistrement de leur worker lient désormais le contrat de ce worker au lieu d'être rejetées, l'exécution sticky avec suffixes d'historique, et la boucle de maintenance purge chaque minute les exécutions expirées.
+
 ### Mettre à niveau de Server 3.0.x vers 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Voici les étapes de schéma antérieures. Si vous passez directement de 3.0.x à 3.5.0, utilisez l'image 3.5.0 à l'étape 3 : son `schema-upgrade` applique ces étapes et celle de 3.5.0 ensemble, et les remarques ci-dessous sur la création d'index PostgreSQL et la reprise sur MySQL restent valables.
+
 Server 3.3.2 franchit trois versions mineures depuis 3.0.x et modifie le schéma
 natif. Sur MySQL, MariaDB et PostgreSQL, il passe de la version 8 (3.0.x et
 3.1.0) à la 10 (3.2.0), puis à la 11 (3.3.0 à 3.3.2). Sur SQLite, il passe de 8
@@ -591,6 +627,8 @@ Une version PHP 2.x existante ne passe pas au natif lors d’une mise à niveau
 
 Le chart 1.1.0 change l’image par défaut de Server 3.0.5 à 3.3.2, ce qui nécessite la [mise à niveau du schéma natif](#native-schema-upgrade-3-0-to-3-3) de 8 à 11. Un `helm upgrade` ordinaire depuis le chart 1.0.x ne change que l’image, et les nouveaux pods refusent de démarrer avec `native_schema_upgrade_required`. Suivez les [étapes Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) du chart : ramenez le Server à zéro réplica avec l’autoscaling désactivé, sauvegardez la base, puis passez au chart 1.1.0 avec `native.schemaUpgrade.enabled=true`. Son hook `pre-upgrade` exécute `schema-upgrade` une fois avant le démarrage des nouveaux pods, et seulement si le `lookup` de Helm montre que tous les Servers sont arrêtés. Les rendus Argo CD, Flux et `helm template` refusent le hook ; utilisez plutôt le Job manuel du README du chart. Un `helm rollback` vers une révision du chart 1.0.x ne rétablit pas le Server, car 3.0.x refuse la base mise à niveau : restaurez plutôt la sauvegarde.
 
+Le chart 1.2.0 passe l'image par défaut à Server 3.4.0 sans changement de schéma : depuis le chart 1.1.0, un simple `helm upgrade` suffit. Les pods native reçoivent aussi une pause `preStop` (`native.preStopSleepSeconds`, 5 par défaut) et un délai de grâce de terminaison de 70 secondes. Le chart 1.3.0 passe l'image par défaut à Server 3.5.0, qui nécessite la [mise à niveau du schéma de 11 à 12](#native-schema-upgrade-3-5) : réduisez le Server à zéro, sauvegardez la base, lancez `helm upgrade` avec `native.schemaUpgrade.enabled=true` (ou le Job manuel), puis remontez le nombre de réplicas. Voir les [notes Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) du chart. Revenir au chart 1.2.0 implique de restaurer cette sauvegarde.
+
 ### Choisir une version du chart {#helm-chart-selection}
 
 Chaque version du chart enregistre l’image Server testée dans l’`appVersion` de `Chart.yaml` ; chart et Server ont des numéros de version indépendants. La [combinaison compatible sélectionnée](./compatibility.md#last-qualified-reproducible-tuple) associe le chart **%%artifact.helmChartVersion%%** à Server **%%artifact.helmChartAppVersion%%**, depuis les mêmes métadonnées que le tableau et la commande d’installation. La [vérification OCI/du paquet publié](%%artifact.helmChartQualificationUrl%%) confirme cette paire, pas une nouvelle installation Kubernetes.
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md
index 31df5cfb374..18f65d586fa 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -377,11 +377,11 @@ curl http://localhost:8080/api/cluster/info \
   -H "Authorization: Bearer $TOKEN"
 ```
 
-Renvoie l’identité du build, les indicateurs de capacités, les manifestes de protocole, les limites et la découverte pour le namespace désigné par `X-Namespace` (ou le paramètre de requête `namespace`, à défaut `default`). Sortie abrégée de l’image 3.3.2 :
+Renvoie l’identité du build, les indicateurs de capacités, les manifestes de protocole, les limites et la découverte pour le namespace désigné par `X-Namespace` (ou le paramètre de requête `namespace`, à défaut `default`). Sortie abrégée de l’image 3.5.0 :
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -422,6 +422,9 @@ Renvoie l’identité du build, les indicateurs de capacités, les manifestes de
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -445,7 +448,8 @@ Renvoie l’identité du build, les indicateurs de capacités, les manifestes de
 Points clés pour le code client :
 
 - La version du build est `version`, pas `server_version`. `implementation` vaut `"rust"` sur le Server natif.
-- Vérifiez `control_plane.version` et `worker_protocol.version` avant d’appeler l’API. Le natif 3.3.2 sert le plan de contrôle `2` et le protocole worker `1.20`, et accepte les requêtes worker annonçant toute version de protocole de `1.0` à `1.20`.
+- Vérifiez `control_plane.version` et `worker_protocol.version` avant d’appeler l’API. Le natif 3.5.0 sert le plan de contrôle `2` et le protocole worker `1.20`, et accepte les requêtes worker annonçant toute version de protocole de `1.0` à `1.20`.
+- Depuis 3.5.0, `worker_protocol.server_capabilities` annonce `sticky_execution` et `sticky_history_suffix`. Depuis 3.4.0, il annonce `activity_workflow_continuation`, qu'un worker n'utilise qu'après sa propre activation.
 - Les commandes de tâche workflow se trouvent sous `worker_protocol.server_capabilities.supported_workflow_task_commands`.
 - Un indicateur de capacité à `false` désigne une fonctionnalité ou un contrat publié que le natif ne sert pas. `response_compression` est vide, car le natif envoie des réponses non compressées.
 - `native_unqualified` liste chaque membre de la réponse PHP 2.x que le natif omet, avec la raison. On y trouve `topology`.
diff --git a/i18n/fr/source-hashes.json b/i18n/fr/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/fr/source-hashes.json
+++ b/i18n/fr/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md b/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md
index 74bfa9ed5bd..8313e4f4319 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md
@@ -170,8 +170,39 @@ docker compose --env-file durable-workflow.prod.env \
 
 ネイティブ Server は起動時にスキーマを確認します。ネイティブの同一マイナー系列内のパッチリリースはスキーマを維持するため、イメージの変更だけで済みます。リリースノートでスキーマ変更が告知されたリリースでは、データベースをバックアップし、全 Server を停止した状態で、イメージの `schema-upgrade` コマンドも実行する必要があります。最新のコマンド例は Server リファレンスの[公式イメージと Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)にあります。
 
+### Server 3.5.0 へのアップグレード {#native-schema-upgrade-3-5}
+
+Server 3.5.0 は native 専用のテーブル `dw_run_command_contracts` を 1 つ追加します。native スキーマは MySQL、MariaDB、PostgreSQL で 11 から 12 に、SQLite で 10 から 11 に上がります。アップグレードはテーブルとそのインデックスを作成するだけで、行は書き換えません。Server 3.4.x のスキーマは 3.3.x と同じなので、3.3.x または 3.4.x からのスキーマ手順はこれだけです。以前のスキーマで起動した Server 3.5.0 は `native_schema_upgrade_required` で起動を拒否します。
+
+単一ノードの Compose デプロイでは次のようにします。
+
+1. MySQL は稼働させたまま、Server を停止します。
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. MySQL と `server_storage` をバックアップし、現在のイメージ参照を記録します。3.4.x へ戻る手段はこのバックアップだけです。
+3. `DW_SERVER_IMAGE` を 3.5.0 イメージに変更し、pull してから `schema-upgrade` を一度実行します。
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   前後のスキーマバージョンを出力します。例: `"from_schema_version":11,"schema_version":12,"status":"upgraded"`。最新のデータベースで再度実行すると `"status":"current"` を返します。
+4. `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` で Server を起動し、`/api/ready`、`/api/cluster/info`（`version` が `3.5.0`）、Worker 登録を確認します。
+
+MySQL と MariaDB では、中断したアップグレードは `schema-upgrade` を再実行すると再開します。3.4.x へのロールバックにはバックアップが必要です。3.4.x の Server はアップグレード済みのデータベースを `native_schema_newer_than_binary` で拒否します。3.0.x から 3.2.x では、同じコマンドが次のセクションで説明する以前の手順も適用します。ワーカープロトコルは `1.20`、コントロールプレーンはバージョン `2` のままです。
+
+実行中のワークフローに対する変更は [3.5.0 リリースノート](https://github.com/durable-workflow/server/releases/tag/3.5.0) にあります。ワーカー登録前に開始した実行への update は拒否されず、そのワーカーのコントラクトに結び付くようになりました。また、履歴サフィックス付きの sticky execution と、メンテナンスループによる期限切れ実行の毎分の削除が加わりました。
+
 ### Server 3.0.x から 3.3.2 へのアップグレード {#native-schema-upgrade-3-0-to-3-3}
 
+以下は以前のスキーマ手順です。3.0.x から直接 3.5.0 に上げる場合は、手順 3 で 3.5.0 イメージを使用してください。その `schema-upgrade` がこれらの手順と 3.5.0 の手順をまとめて適用します。PostgreSQL のインデックス構築と MySQL での再開に関する以下の注意は引き続き当てはまります。
+
 Server 3.3.2 は 3.0.x から 3 つのマイナーリリースをまたぎ、ネイティブのスキーマを変更します。MySQL、MariaDB、PostgreSQL では、バージョン 8（3.0.x と 3.1.0）から 10（3.2.0）を経て 11（3.3.0～3.3.2）へ移行します。SQLite では 8 から 10 へ移行します。Server が起動時にスキーマをアップグレードすることはありません。3.3.2 はバージョン 8 のデータベースで起動すると `native_schema_upgrade_required` で拒否するため、`DW_SERVER_IMAGE` を変更するだけでは新しい Server を起動できません。3.3.2 イメージの `schema-upgrade` コマンドは、バージョン 8 のデータベースを直接アップグレードします。[3.3.0 のアップグレードノート](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade)がこの手順を説明し、Helm チャートの[チャート 1.1.0 / Server 3.3.2 のノート](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)が、3.0.5 から 3.3.2 までのスキーマ手順とランタイムの変更を列挙しています。
 
 単一ノードの Compose デプロイでは次のようにします。
@@ -373,6 +404,8 @@ helm install durable-workflow \
 
 チャート 1.1.0 は既定のイメージを Server 3.0.5 から 3.3.2 に変更します。3.3.2 には 8 から 11 への[ネイティブスキーマのアップグレード](#native-schema-upgrade-3-0-to-3-3)が必要です。チャート 1.0.x からの通常の `helm upgrade` はイメージだけを変更するため、新しい Pod は `native_schema_upgrade_required` で起動を拒否します。チャートの[チャート 1.1.0 / Server 3.3.2 の手順](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)に従ってください。オートスケーリングを無効にして Server をゼロにスケールし、データベースをバックアップしてから、`native.schemaUpgrade.enabled=true` でチャート 1.1.0 にアップグレードします。その `pre-upgrade` フックは、新しい Pod の起動前に `schema-upgrade` を一度実行します。ただし実行するのは、Helm の `lookup` ですべての Server が停止していると確認できる場合だけです。Argo CD、Flux、`helm template` によるレンダリングではフックが拒否されるため、代わりにチャート README の手動 Job を使ってください。チャート 1.0.x のリビジョンへ `helm rollback` しても Server は戻りません。3.0.x はアップグレード済みのデータベースを拒否するためです。代わりにバックアップを復元してください。
 
+Chart 1.2.0 はスキーマ変更なしでデフォルトイメージを Server 3.4.0 に変更するため、chart 1.1.0 からは通常の `helm upgrade` で十分です。native Pod には `preStop` のスリープ（`native.preStopSleepSeconds`、デフォルト 5）と 70 秒の終了猶予期間も追加されます。Chart 1.3.0 はデフォルトイメージを Server 3.5.0 に変更し、[スキーマの 11 から 12 へのアップグレード](#native-schema-upgrade-3-5) が必要です。Server をゼロにスケールし、データベースをバックアップしてから、`native.schemaUpgrade.enabled=true` を付けて `helm upgrade`（または手動 Job）を実行し、スケールを戻します。チャートの [Chart 1.3.0 / Server 3.5.0 の注意事項](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) を参照してください。chart 1.2.0 に戻すにはこのバックアップの復元が必要です。
+
 ### チャートのリリースを選ぶ {#helm-chart-selection}
 
 各チャートリリースは、テスト対象の Server イメージを `Chart.yaml` の `appVersion` に記録します。チャートと Server のバージョン番号は独立しています。選択した[互換な組み合わせ](./compatibility.md#last-qualified-reproducible-tuple)は、チャート **%%artifact.helmChartVersion%%** と Server **%%artifact.helmChartAppVersion%%** で、表やインストールコマンドと同じリリースメタデータに基づきます。[公開済み OCI/パッケージの検証記録](%%artifact.helmChartQualificationUrl%%)が確認するのはその組み合わせであり、新たな Kubernetes インストールではありません。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md
index 1e9e62f6ed3..11a47f9d080 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -367,11 +367,11 @@ curl http://localhost:8080/api/cluster/info \
   -H "Authorization: Bearer $TOKEN"
 ```
 
-ビルド識別、能力フラグ、プロトコルのマニフェスト、制限値、そして `X-Namespace`（または `namespace` クエリパラメーター、どちらもなければ `default`）で指定した Namespace の検出情報を返します。3.3.2 イメージの出力を抜粋します。
+ビルド識別、能力フラグ、プロトコルのマニフェスト、制限値、そして `X-Namespace`（または `namespace` クエリパラメーター、どちらもなければ `default`）で指定した Namespace の検出情報を返します。3.5.0 イメージの出力を抜粋します。
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -412,6 +412,9 @@ curl http://localhost:8080/api/cluster/info \
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -435,7 +438,8 @@ curl http://localhost:8080/api/cluster/info \
 クライアントコード向けの主なフィールドの注意点：
 
 - ビルドバージョンは `server_version` ではなく `version` です。ネイティブ Server では `implementation` が `"rust"` です。
-- API を呼び出す前に `control_plane.version` と `worker_protocol.version` を確認してください。ネイティブ 3.3.2 はコントロールプレーン `2` と Worker プロトコル `1.20` を提供し、`1.0` から `1.20` までの任意のプロトコルバージョンを送る Worker 要求を受け付けます。
+- API を呼び出す前に `control_plane.version` と `worker_protocol.version` を確認してください。ネイティブ 3.5.0 はコントロールプレーン `2` と Worker プロトコル `1.20` を提供し、`1.0` から `1.20` までの任意のプロトコルバージョンを送る Worker 要求を受け付けます。
+- 3.5.0 以降、`worker_protocol.server_capabilities` は `sticky_execution` と `sticky_history_suffix` を示します。3.4.0 以降は `activity_workflow_continuation` も示しますが、ワーカーが使うのは自身でオプトインした場合だけです。
 - ワークフロータスクのコマンドは `worker_protocol.server_capabilities.supported_workflow_task_commands` にあります。
 - `false` の能力フラグは、ネイティブが提供しない機能や公開契約を示します。ネイティブは圧縮しない応答を送るため、`response_compression` は空です。
 - `native_unqualified` は、PHP 2.x の応答のうちネイティブが含めない各メンバーを理由とともに列挙します。`topology` が含まれます。
diff --git a/i18n/ja/source-hashes.json b/i18n/ja/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/ja/source-hashes.json
+++ b/i18n/ja/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md
index 241cffe1389..b20179a883f 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md
@@ -275,8 +275,44 @@ todos os Servers parados. A referência do Server mantém os exemplos mais
 recentes de comandos Compose na seção
 [Imagem oficial + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Atualizar para o Server 3.5.0 {#native-schema-upgrade-3-5}
+
+O Server 3.5.0 adiciona uma tabela exclusiva do native, `dw_run_command_contracts`. O esquema native passa de 11 para 12 no MySQL, MariaDB e PostgreSQL, e de 10 para 11 no SQLite. A atualização cria a tabela e seu índice e não reescreve nenhuma linha. O Server 3.4.x tem o mesmo esquema do 3.3.x, então esta é a única etapa de esquema a partir do 3.3.x ou 3.4.x. Um Server 3.5.0 iniciado no esquema anterior se recusa a iniciar com `native_schema_upgrade_required`.
+
+Para a implantação Compose em nó único:
+
+1. Pare o Server e deixe o MySQL em execução:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Faça backup do MySQL e do `server_storage` e registre a referência da
+   imagem atual. Esse backup é o único caminho de volta para a 3.4.x.
+3. Altere `DW_SERVER_IMAGE` para a imagem 3.5.0, baixe-a e execute
+   `schema-upgrade` uma vez:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   Ele mostra as versões do esquema antes e depois, por exemplo `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Executado de novo em um banco atual, ele informa `"status":"current"`.
+4. Inicie o Server com
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`,
+   depois confirme `/api/ready`, `/api/cluster/info` (`version` é `3.5.0`) e o
+   registro de workers.
+
+No MySQL e no MariaDB, uma atualização interrompida é retomada quando você executa `schema-upgrade` de novo. Voltar para o 3.4.x exige o backup: um Server 3.4.x recusa o banco atualizado com `native_schema_newer_than_binary`. Do 3.0.x ao 3.2.x, o mesmo comando também aplica as etapas anteriores descritas na próxima seção. O protocolo de workers continua em `1.20` e o plano de controle na versão `2`.
+
+O que muda para workflows em execução está nas [notas da versão 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0): updates de execuções iniciadas antes de o worker se registrar agora vinculam o contrato desse worker em vez de serem rejeitados, execução sticky com sufixos de histórico, e o loop de manutenção remove a cada minuto as execuções expiradas.
+
 ### Atualizar do Server 3.0.x para o 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Estas são as etapas de esquema anteriores. Se você for do 3.0.x direto para o 3.5.0, use a imagem 3.5.0 na etapa 3: o `schema-upgrade` dela aplica estas etapas e a do 3.5.0 juntas, e as observações abaixo sobre a criação de índices no PostgreSQL e a retomada no MySQL continuam valendo.
+
 O Server 3.3.2 atravessa três versões minor a partir da 3.0.x e muda o schema
 nativo. No MySQL, MariaDB e PostgreSQL, ele passa da versão 8 (3.0.x e 3.1.0)
 pela 10 (3.2.0) até a 11 (3.3.0 a 3.3.2). No SQLite, passa da 8 para a 10. Um
@@ -601,6 +637,8 @@ Uma release PHP 2.x existente não passa para o modo nativo em uma atualização
 
 O chart 1.1.0 muda a imagem padrão do Server 3.0.5 para o 3.3.2, que exige a [atualização do schema nativo](#native-schema-upgrade-3-0-to-3-3) da versão 8 para a 11. Um `helm upgrade` comum a partir do chart 1.0.x altera apenas a imagem, e os novos pods se recusam a iniciar com `native_schema_upgrade_required`. Siga as [etapas Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) do chart: reduza o Server a zero réplicas com o escalonamento automático desativado, faça backup do banco de dados e então atualize para o chart 1.1.0 com `native.schemaUpgrade.enabled=true`. O hook `pre-upgrade` do chart executa `schema-upgrade` uma vez antes de os novos pods iniciarem, e somente quando o `lookup` do Helm mostra todos os Servers parados. Renderizações do Argo CD, do Flux e do `helm template` recusam o hook; nesses casos, use o Job manual do README do chart. Um `helm rollback` para uma revisão do chart 1.0.x não traz o Server de volta, porque a 3.0.x recusa o banco de dados atualizado: em vez disso, restaure o backup.
 
+O chart 1.2.0 muda a imagem padrão para o Server 3.4.0 sem mudança de esquema, então a partir do chart 1.1.0 basta um `helm upgrade` comum. Os pods native também ganham uma pausa `preStop` (`native.preStopSleepSeconds`, padrão 5) e um período de carência de encerramento de 70 segundos. O chart 1.3.0 muda a imagem padrão para o Server 3.5.0, que precisa da [atualização de esquema de 11 para 12](#native-schema-upgrade-3-5): escale o Server para zero, faça backup do banco e execute `helm upgrade` com `native.schemaUpgrade.enabled=true` (ou o Job manual), depois escale de volta. Veja as [notas do Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) do chart. Voltar para o chart 1.2.0 significa restaurar esse backup.
+
 ### Escolher uma versão do chart {#helm-chart-selection}
 
 Cada versão do chart registra em `appVersion` do `Chart.yaml` a imagem do Server com que foi testada; chart e Server têm números de versão independentes. A [combinação compatível selecionada](./compatibility.md#last-qualified-reproducible-tuple) associa o chart **%%artifact.helmChartVersion%%** ao Server **%%artifact.helmChartAppVersion%%**, usando os mesmos metadados da tabela e do comando de instalação. A [verificação OCI/do pacote publicado](%%artifact.helmChartQualificationUrl%%) comprova esse par, não uma nova instalação Kubernetes.
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md
index 769f2bfb3c1..2ae2b208cad 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -377,11 +377,11 @@ curl http://localhost:8080/api/cluster/info \
   -H "Authorization: Bearer $TOKEN"
 ```
 
-Retorna a identidade da compilação, os indicadores de capacidade, os manifestos de protocolo, os limites e a descoberta do namespace indicado por `X-Namespace` (ou pelo parâmetro de consulta `namespace`; na ausência de ambos, `default`). Saída resumida da imagem 3.3.2:
+Retorna a identidade da compilação, os indicadores de capacidade, os manifestos de protocolo, os limites e a descoberta do namespace indicado por `X-Namespace` (ou pelo parâmetro de consulta `namespace`; na ausência de ambos, `default`). Saída resumida da imagem 3.5.0:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -422,6 +422,9 @@ Retorna a identidade da compilação, os indicadores de capacidade, os manifesto
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -445,7 +448,8 @@ Retorna a identidade da compilação, os indicadores de capacidade, os manifesto
 Notas sobre os principais campos para o código cliente:
 
 - A versão de compilação está em `version`, não em `server_version`. `implementation` é `"rust"` no Server nativo.
-- Verifique `control_plane.version` e `worker_protocol.version` antes de chamar a API. O nativo 3.3.2 serve o plano de controle `2` e o protocolo dos workers `1.20`, e aceita requisições de workers que enviem qualquer versão de protocolo de `1.0` a `1.20`.
+- Verifique `control_plane.version` e `worker_protocol.version` antes de chamar a API. O nativo 3.5.0 serve o plano de controle `2` e o protocolo dos workers `1.20`, e aceita requisições de workers que enviem qualquer versão de protocolo de `1.0` a `1.20`.
+- Desde o 3.5.0, `worker_protocol.server_capabilities` anuncia `sticky_execution` e `sticky_history_suffix`. Desde o 3.4.0, anuncia `activity_workflow_continuation`, que um worker só usa depois de ativá-lo explicitamente.
 - Os comandos de tarefas de workflow ficam em `worker_protocol.server_capabilities.supported_workflow_task_commands`.
 - Um indicador de capacidade definido como `false` identifica um recurso ou contrato publicado que o Server nativo não oferece. `response_compression` está vazio porque o Server nativo envia respostas sem compressão.
 - `native_unqualified` lista cada membro da resposta do PHP 2.x que o Server nativo omite, com o motivo. Inclui `topology`.
diff --git a/i18n/pt-BR/source-hashes.json b/i18n/pt-BR/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/pt-BR/source-hashes.json
+++ b/i18n/pt-BR/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md b/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md
index c4ce90de150..790647a7dcc 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md
@@ -269,8 +269,44 @@ docker compose --env-file durable-workflow.prod.env \
 розділі
 [Official Image + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose).
 
+### Оновлення до Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 додає одну таблицю лише для native, `dw_run_command_contracts`. Нативна схема переходить з 11 на 12 у MySQL, MariaDB і PostgreSQL та з 10 на 11 у SQLite. Оновлення створює таблицю та її індекс і не переписує жодних рядків. Server 3.4.x має ту саму схему, що й 3.3.x, тому з 3.3.x або 3.4.x це єдиний крок схеми. Server 3.5.0, запущений на попередній схемі, відмовляється стартувати з `native_schema_upgrade_required`.
+
+Для одновузлового розгортання Compose:
+
+1. Зупиніть Server, залишивши MySQL запущеним:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. Створіть резервні копії MySQL і `server_storage` та запишіть поточне
+   посилання на образ. Ця резервна копія — єдиний шлях назад до 3.4.x.
+3. Змініть `DW_SERVER_IMAGE` на образ 3.5.0, завантажте його й один раз
+   виконайте `schema-upgrade`:
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   Команда виводить версії схеми до й після, наприклад `"from_schema_version":11,"schema_version":12,"status":"upgraded"`. Повторний запуск на актуальній базі повідомляє `"status":"current"`.
+4. Запустіть Server командою
+   `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait`,
+   потім перевірте `/api/ready`, `/api/cluster/info` (`version` дорівнює
+   `3.5.0`) та реєстрацію worker.
+
+У MySQL і MariaDB перерване оновлення продовжується, коли ви знову запускаєте `schema-upgrade`. Повернення до 3.4.x потребує резервної копії: Server 3.4.x відхиляє оновлену базу з `native_schema_newer_than_binary`. Для версій від 3.0.x до 3.2.x та сама команда також застосовує попередні кроки з наступного розділу. Протокол workers лишається `1.20`, а площина керування — версії `2`.
+
+Що змінюється для запущених workflows, описано в [примітках до випуску 3.5.0](https://github.com/durable-workflow/server/releases/tag/3.5.0): updates для запусків, стартованих до реєстрації їхнього worker, тепер прив’язують контракт цього worker замість відхилення; sticky execution із суфіксами історії; а цикл обслуговування щохвилини видаляє прострочені запуски.
+
 ### Оновлення з Server 3.0.x до 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+Це попередні кроки схеми. Якщо ви переходите з 3.0.x одразу на 3.5.0, використайте образ 3.5.0 на кроці 3: його `schema-upgrade` застосовує ці кроки та крок 3.5.0 разом, а примітки нижче про побудову індексів у PostgreSQL і продовження в MySQL лишаються чинними.
+
 Server 3.3.2 відділяють від 3.0.x три мінорні випуски, і він змінює нативну
 схему. На MySQL, MariaDB і PostgreSQL вона переходить з версії 8 (3.0.x і
 3.1.0) через 10 (3.2.0) до 11 (від 3.3.0 до 3.3.2). На SQLite вона переходить
@@ -581,6 +617,8 @@ helm install durable-workflow \
 
 Чарт 1.1.0 змінює типовий образ із Server 3.0.5 на 3.3.2, якому потрібне [нативне оновлення схеми](#native-schema-upgrade-3-0-to-3-3) з 8 до 11. Звичайний `helm upgrade` із чарта 1.0.x змінює лише образ, і нові Pod відмовляються запускатися з `native_schema_upgrade_required`. Дотримуйтеся [кроків Chart 1.1.0 / Server 3.3.2](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native) чарта: масштабуйте Server до нуля з вимкненим автомасштабуванням, створіть резервну копію бази, а потім оновіться до чарта 1.1.0 з `native.schemaUpgrade.enabled=true`. Його hook `pre-upgrade` один раз виконує `schema-upgrade` перед запуском нових Pod і лише тоді, коли `lookup` Helm показує, що всі Server зупинені. Рендеринг через Argo CD, Flux і `helm template` відхиляє цей hook; натомість використовуйте ручний Job із README чарта. `helm rollback` до ревізії чарта 1.0.x не повертає Server, бо 3.0.x відмовляє оновленій базі: натомість відновіть резервну копію.
 
+Chart 1.2.0 змінює типовий образ на Server 3.4.0 без зміни схеми, тому з chart 1.1.0 достатньо звичайного `helm upgrade`. Нативні pods також отримують паузу `preStop` (`native.preStopSleepSeconds`, типово 5) і 70-секундний період завершення. Chart 1.3.0 змінює типовий образ на Server 3.5.0, якому потрібне [оновлення схеми з 11 до 12](#native-schema-upgrade-3-5): масштабуйте Server до нуля, зробіть резервну копію бази й виконайте `helm upgrade` з `native.schemaUpgrade.enabled=true` (або ручний Job), а потім масштабуйте назад. Див. [примітки Chart 1.3.0 / Server 3.5.0](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native) до чарту. Повернення до chart 1.2.0 означає відновлення цієї копії.
+
 ### Вибір випуску чарту {#helm-chart-selection}
 
 Кожен випуск чарту записує образ Server, з яким його перевіряли, у `appVersion` файлу `Chart.yaml`; номери версій чарту й Server незалежні. Вибрана [сумісна комбінація](./compatibility.md#last-qualified-reproducible-tuple) поєднує чарт **%%artifact.helmChartVersion%%** із Server **%%artifact.helmChartAppVersion%%**, використовуючи ті самі метадані випусків, що й таблиця та команда встановлення. [Підтвердження опублікованих OCI/package](%%artifact.helmChartQualificationUrl%%) перевіряє цю пару, а не нове встановлення Kubernetes.
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md
index 0c04a454211..8e8a2299c4c 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -506,11 +506,11 @@ curl http://localhost:8080/api/cluster/info \
 
 Повертає ідентичність збірки, прапорці можливостей, маніфести протоколів,
 ліміти та дані виявлення для namespace, названого в `X-Namespace` (або в
-параметрі запиту `namespace`, інакше `default`). Скорочений вивід образу 3.3.2:
+параметрі запиту `namespace`, інакше `default`). Скорочений вивід образу 3.5.0:
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -551,6 +551,9 @@ curl http://localhost:8080/api/cluster/info \
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -576,11 +579,12 @@ curl http://localhost:8080/api/cluster/info \
 - Версія збірки міститься в `version`, а не в `server_version`. На нативному
   Server `implementation` має значення `"rust"`.
 - Перевіряйте `control_plane.version` і `worker_protocol.version` перед
-  викликами API. Нативний 3.3.2 обслуговує площину керування `2` і протокол
+  викликами API. Нативний 3.5.0 обслуговує площину керування `2` і протокол
   worker `1.20`, а також приймає запити worker із будь-якою версією протоколу
   від `1.0` до `1.20`.
 - Команди workflow-task містяться в
   `worker_protocol.server_capabilities.supported_workflow_task_commands`.
+- Починаючи з 3.5.0, `worker_protocol.server_capabilities` оголошує `sticky_execution` і `sticky_history_suffix`. Починаючи з 3.4.0, воно оголошує `activity_workflow_continuation`, яке worker використовує лише після власного ввімкнення.
 - Прапорець можливості зі значенням `false` позначає функцію чи опублікований
   контракт, який нативний Server не обслуговує. `response_compression`
   порожній, бо нативний Server надсилає нестиснені відповіді.
diff --git a/i18n/uk/source-hashes.json b/i18n/uk/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/uk/source-hashes.json
+++ b/i18n/uk/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md
index ec25337093c..007bfef8d29 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md
@@ -169,8 +169,39 @@ docker compose --env-file durable-workflow.prod.env \
 
 原生 Server 在启动时检查其数据库模式。同一原生次版本线内的补丁发布保持模式不变，因此只需更换镜像。发布说明中宣布模式变更的版本还需要运行镜像的 `schema-upgrade` 命令，须在备份数据库后、所有 Server 都已停止时执行。Server 参考文档的[官方镜像 + Compose](https://github.com/durable-workflow/server/blob/main/docs/server-reference.md#official-image--compose)部分维护最新命令级 Compose 示例。
 
+### 升级到 Server 3.5.0 {#native-schema-upgrade-3-5}
+
+Server 3.5.0 新增一张仅用于 native 的表 `dw_run_command_contracts`。native 架构在 MySQL、MariaDB 和 PostgreSQL 上从 11 升到 12，在 SQLite 上从 10 升到 11。升级只创建该表及其索引，不改写任何行。Server 3.4.x 与 3.3.x 的架构相同，因此从 3.3.x 或 3.4.x 升级只有这一个架构步骤。在旧架构上启动的 Server 3.5.0 会以 `native_schema_upgrade_required` 拒绝启动。
+
+对于单节点 Compose 部署：
+
+1. 停止 Server，保持 MySQL 运行：
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml stop server
+   ```
+2. 备份 MySQL 和 `server_storage`，并记录当前镜像引用。此备份是回到 3.4.x 的唯一途径。
+3. 将 `DW_SERVER_IMAGE` 改为 3.5.0 镜像，拉取该镜像，并运行一次 `schema-upgrade`：
+
+   ```bash
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml pull server
+   docker compose --env-file durable-workflow.prod.env \
+     -f docker-compose.published.yml run --rm --no-deps server schema-upgrade
+   ```
+
+   它会输出升级前后的架构版本，例如 `"from_schema_version":11,"schema_version":12,"status":"upgraded"`。在已是最新的数据库上再次运行时，它报告 `"status":"current"`。
+4. 使用 `docker compose --env-file durable-workflow.prod.env -f docker-compose.published.yml up -d --wait` 启动 Server，然后确认 `/api/ready`、`/api/cluster/info`（`version` 为 `3.5.0`）和 Worker 注册。
+
+在 MySQL 和 MariaDB 上，再次运行 `schema-upgrade` 即可继续被中断的升级。回滚到 3.4.x 需要备份：3.4.x Server 会以 `native_schema_newer_than_binary` 拒绝已升级的数据库。从 3.0.x 到 3.2.x，同一命令也会应用下一节所述的早期步骤。Worker 协议仍为 `1.20`，控制平面仍为版本 `2`。
+
+正在运行的工作流有哪些变化，请见 [3.5.0 发布说明](https://github.com/durable-workflow/server/releases/tag/3.5.0)：在 worker 注册前启动的运行，其 update 现在会绑定该 worker 的契约而不再被拒绝；支持带历史后缀的 sticky execution；维护循环每分钟清理过期运行。
+
 ### 从 Server 3.0.x 升级到 3.3.2 {#native-schema-upgrade-3-0-to-3-3}
 
+以下是早期的架构步骤。如果从 3.0.x 直接升级到 3.5.0，请在第 3 步使用 3.5.0 镜像：它的 `schema-upgrade` 会一并应用这些步骤和 3.5.0 的步骤，下面关于 PostgreSQL 索引构建和 MySQL 续做的说明仍然适用。
+
 从 3.0.x 到 Server 3.3.2 跨越三个次版本，并会变更原生数据库模式。在 MySQL、MariaDB 和 PostgreSQL 上，模式版本从 8（3.0.x 和 3.1.0）经 10（3.2.0）升至 11（3.3.0 至 3.3.2）。在 SQLite 上，模式版本从 8 升至 10。Server 从不在启动时升级其数据库模式：在版本 8 的数据库上启动 3.3.2 会以 `native_schema_upgrade_required` 拒绝启动，因此仅修改 `DW_SERVER_IMAGE` 会使新 Server 无法启动。3.3.2 镜像的 `schema-upgrade` 命令可将版本 8 的数据库直接升级。[3.3.0 升级说明](https://github.com/durable-workflow/server/blob/3.3.2/docs/releases/3.3.0.md#upgrade)描述了这一步骤，Helm chart 的 [Chart 1.1.0 / Server 3.3.2 说明](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)列出了各模式升级步骤以及从 3.0.5 到 3.3.2 的运行时变更。
 
 对于单节点 Compose 部署：
@@ -362,6 +393,8 @@ Chart 1.x 默认运行原生 Server（`runtime: native`）：一个 Server Deplo
 
 Chart 1.1.0 将默认镜像从 Server 3.0.5 改为 3.3.2，后者需要执行从 8 到 11 的[原生数据库模式升级](#native-schema-upgrade-3-0-to-3-3)。从 Chart 1.0.x 执行普通 `helm upgrade` 只会更换镜像，新 Pod 会以 `native_schema_upgrade_required` 拒绝启动。请按照 Chart 的 [Chart 1.1.0 / Server 3.3.2 步骤](%%artifact.helmChartUpgradeUrl%%#chart-110--server-332-native)操作：在关闭自动扩缩的情况下将 Server 缩容至零，备份数据库，然后使用 `native.schemaUpgrade.enabled=true` 升级到 Chart 1.1.0。其 `pre-upgrade` 钩子会在新 Pod 启动前运行一次 `schema-upgrade`，且仅在 Helm 的 `lookup` 显示所有 Server 均已停止时运行。Argo CD、Flux 和 `helm template` 渲染会拒绝该钩子；请改用 Chart README 中的手动 Job。`helm rollback` 回到 Chart 1.0.x 修订版本无法让 Server 恢复运行，因为 3.0.x 会拒绝已升级的数据库：请改为恢复备份。
 
+Chart 1.2.0 将默认镜像改为 Server 3.4.0，没有架构变化，因此从 chart 1.1.0 只需普通的 `helm upgrade`。native Pod 还增加了 `preStop` 休眠（`native.preStopSleepSeconds`，默认 5）和 70 秒的终止宽限期。Chart 1.3.0 将默认镜像改为 Server 3.5.0，需要[将架构从 11 升级到 12](#native-schema-upgrade-3-5)：将 Server 缩容到零，备份数据库，使用 `native.schemaUpgrade.enabled=true` 运行 `helm upgrade`（或手动 Job），然后恢复副本数。参见该 chart 的 [Chart 1.3.0 / Server 3.5.0 说明](%%artifact.helmChartUpgradeUrl%%#chart-130--server-350-native)。回到 chart 1.2.0 需要恢复该备份。
+
 ### 选择 Chart 版本 {#helm-chart-selection}
 
 每个 Chart 发布版都会在 `Chart.yaml` 的 `appVersion` 中记录其测试过的 Server 镜像；Chart 与 Server 的版本号彼此独立。所选[兼容组合](./compatibility.md#last-qualified-reproducible-tuple)使用 Chart **%%artifact.helmChartVersion%%** 和 Server **%%artifact.helmChartAppVersion%%**，与表格和安装命令共享同一份发布元数据。[已发布 OCI/软件包的验证记录](%%artifact.helmChartQualificationUrl%%)核实的是这个组合，并非一次新的 Kubernetes 安装。
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md
index 1047b0af7ed..89848d3482c 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -366,11 +366,11 @@ curl http://localhost:8080/api/cluster/info \
   -H "Authorization: Bearer $TOKEN"
 ```
 
-返回构建标识、能力标志、协议清单、限制，以及由 `X-Namespace`（或 `namespace` 查询参数，否则为 `default`）指定的命名空间的发现信息。以下为 3.3.2 镜像的节选输出：
+返回构建标识、能力标志、协议清单、限制，以及由 `X-Namespace`（或 `namespace` 查询参数，否则为 `default`）指定的命名空间的发现信息。以下为 3.5.0 镜像的节选输出：
 
 ```json
 {
-  "version": "3.3.2",
+  "version": "3.5.0",
   "implementation": "rust",
   "development": false,
   "server_id": "2145ce2abb12",
@@ -411,6 +411,9 @@ curl http://localhost:8080/api/cluster/info \
       "supported_workflow_task_commands": ["schedule_activity", "start_timer", "complete_workflow", "..."],
       "query_tasks": true,
       "workflow_updates": true,
+      "sticky_execution": { "supported": true, "...": "..." },
+      "sticky_history_suffix": { "supported": true, "version": 1 },
+      "activity_workflow_continuation": { "version": 1, "...": "..." },
       "...": "..."
     }
   },
@@ -434,7 +437,8 @@ curl http://localhost:8080/api/cluster/info \
 面向客户端代码的关键字段说明：
 
 - 构建版本是 `version`，而不是 `server_version`。在原生 Server 上，`implementation` 为 `"rust"`。
-- 调用 API 之前，请检查 `control_plane.version` 和 `worker_protocol.version`。原生 3.3.2 提供控制平面 `2` 与 Worker 协议 `1.20`，并接受发送 `1.0` 至 `1.20` 之间任一协议版本的 Worker 请求。
+- 调用 API 之前，请检查 `control_plane.version` 和 `worker_protocol.version`。原生 3.5.0 提供控制平面 `2` 与 Worker 协议 `1.20`，并接受发送 `1.0` 至 `1.20` 之间任一协议版本的 Worker 请求。
+- 自 3.5.0 起，`worker_protocol.server_capabilities` 声明 `sticky_execution` 和 `sticky_history_suffix`。自 3.4.0 起还声明 `activity_workflow_continuation`，worker 只有在自行启用后才会使用它。
 - 工作流任务命令位于 `worker_protocol.server_capabilities.supported_workflow_task_commands`。
 - 值为 `false` 的能力标志表示原生 Server 不提供的功能或已发布契约。`response_compression` 为空，因为原生 Server 发送未压缩的响应。
 - `native_unqualified` 列出原生 Server 省略的每个 PHP 2.x 响应成员及其原因，其中包括 `topology`。
diff --git a/i18n/zh-Hans/source-hashes.json b/i18n/zh-Hans/source-hashes.json
index 42087c48831..66c6f986129 100644
--- a/i18n/zh-Hans/source-hashes.json
+++ b/i18n/zh-Hans/source-hashes.json
@@ -28,7 +28,7 @@
   "defining-workflows/workflow-id.md": "ca3b43253a748b27dca1af9f82fcf8c4c133e14f13e1b82eaa1ca2ed0996d4bf",
   "defining-workflows/workflow-status.md": "8e8cb27ff44c890d489d89bf166375acfdfaecabd990a2235e106fab1592d529",
   "defining-workflows/workflows.md": "f467bc73de32aa5d722c61ce085065460382ae7dd44cea4625847d9fcdc4c97c",
-  "deployment.md": "52490cc5b048b880746326f1c441fff88398f564d2af6d0a92cc671d1d7ecaf7",
+  "deployment.md": "69d24711e8622c949f783f224d39932f9f2d217913558073ea25a7d5df318455",
   "failures-and-recovery.md": "4c8c35e1cffc6382f5fa16790d04ac377c1697aa157273f364a8c24532569d2c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -91,7 +91,7 @@
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
   "polyglot/server-config-reference.md": "6c28075a3245c30d54e4d7578f63519e9ad1e407bd72bf47121e0d055e0f60fc",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "682aed5dfad3f48f76523993f6403f144fc5f4aa5659707396beeff2afc3c043",
+  "polyglot/server.md": "d4f4c0640b862d772b03990457a47950be08a05123d25f9b4d7432da0a034b70",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",
diff --git a/static/stable-releases.json b/static/stable-releases.json
index a8613bbc3cb..0dd4a18a50e 100644
--- a/static/stable-releases.json
+++ b/static/stable-releases.json
@@ -4,20 +4,20 @@
   "updated_at": "2026-11-12",
   "artifacts": {
     "cli": "2.5.0",
-    "helm-chart": "1.1.0",
+    "helm-chart": "1.3.0",
     "sdk-php": "3.11.0",
     "sdk-python": "2.14.1",
     "sdk-rust": "4.12.0",
-    "server": "3.3.2",
+    "server": "3.5.0",
     "waterline": "2.14.0",
     "workflow": "2.22.0"
   },
   "helm_chart": {
-    "app_version": "3.3.2",
+    "app_version": "3.5.0",
     "repository": "oci://ghcr.io/durable-workflow/charts/durable-workflow",
-    "oci_manifest_digest": "sha256:fd670cad2d12453f5d9923bacaec2ab6fba02ff7fe82570eee8f01f66bf73e89",
-    "package_digest": "sha256:a72dc4fda8a1c8913d19ad6611558e938a74c6dc109dd973a8bfcbce799c2e5d",
-    "source_commit": "0eea994a7f4796ceaec536604c7bd48af11124e2",
-    "qualification_url": "https://github.com/durable-workflow/server/pull/1117#issuecomment-6744052774"
+    "oci_manifest_digest": "sha256:2355dba8dcdbdd040bf534572d2f6ed77efb906ae98d48d1194b8c2540c26b99",
+    "package_digest": "sha256:27ccf139ebedb66dfe351816742c177630c7ec7227a378b8e98842168369fdd9",
+    "source_commit": "66c0196ce1bc5288dfa87a1272dfe5ae3d8443fa",
+    "qualification_url": "https://github.com/durable-workflow/server/pull/1149#issuecomment-6810960429"
   }
 }
diff --git a/tests/kubernetes-workers/artifacts.json b/tests/kubernetes-workers/artifacts.json
index 3dce7328832..dc3731d0766 100644
--- a/tests/kubernetes-workers/artifacts.json
+++ b/tests/kubernetes-workers/artifacts.json
@@ -1,6 +1,6 @@
 {
-  "server": "durableworkflow/server@sha256:4aeceb423ee4c8931f00ec2936149ac6b2a75479243b3930f9c6336ccdebf912",
-  "server_version": "3.3.2",
+  "server": "durableworkflow/server@sha256:b5776fea2a4627ebc477b3b350caaf600dc220e7ab75aa29d32b70e404fd7a68",
+  "server_version": "3.5.0",
   "php_sdk": "3.4.1",
   "php_source": "cb1d11e57767e20e1fdb8081024f67057ff66714",
   "python_sdk": "2.9.0",