From 98907a1dfb87f874ad0ed97b61b5ec541e3fbc1b Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:05:03 +0000
Subject: [PATCH 1/6] Prepare Server 3.9.1 upgrade and published limit guidance

---
 docs/deployment.md                       | 29 +++++++++++++++
 docs/polyglot/server-config-reference.md | 46 ++++++++++++++----------
 docs/polyglot/server.md                  |  2 ++
 3 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/docs/deployment.md b/docs/deployment.md
index 5ba46759dd2..5e71eb7353b 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -268,6 +268,35 @@ 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.9.1 {#native-schema-upgrade-3-9}
+
+Upgrading from native 3.8.x or earlier requires a schema upgrade on every
+backend. Server 3.9.1 adds the empty `dw_command_intents` table:
+
+| Backend | Schema transition from 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Stop every Server replica, keep the database running, back up the database and
+Server storage, then select and pull the 3.9.1 image. Run that image's
+`schema-upgrade` once before restarting every replica on the same version.
+Server does not upgrade an existing schema at startup: it refuses an old
+schema with `native_schema_upgrade_required`. Verify readiness, reported
+version and worker registration after restart. The
+[qualified 3.9.1 release instructions](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade)
+provide the source-free Compose commands.
+
+MySQL and MariaDB upgrades resume after interruption; SQLite and PostgreSQL
+apply the step transactionally. Rollback to 3.8.x requires restoring the backup:
+3.8.0 refuses the upgraded database with `native_schema_newer_than_binary`.
+From 3.9.0, no further schema step is needed. From older versions,
+`schema-upgrade` applies the earlier steps too, including the
+[3.7 JSON rebuild](#native-schema-upgrade-3-7) where applicable. Worker protocol
+1.20 and control plane 2 are unchanged.
+
 ### Upgrading to Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 needs a native schema upgrade on every backend. It adds one
diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index 687e1d06e82..a15d70755b4 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -403,7 +403,7 @@ limit; child-call fields have stricter bounds than other commands.
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-Native 3.8.0 and the corrected source also retain UTF-8 byte checks.
+Native 3.8.0 and 3.9.1 also retain UTF-8 byte checks.
 `activity_type`, `open_signal_wait.signal_name`, an explicit
 `schedule_activity.queue`, and `continue_as_new.workflow_type` / `queue`
 use a 255-byte parser ceiling (`422 invalid_request`). Child `workflow_type`
@@ -412,15 +412,14 @@ and `queue` have an additional 191-byte guard that can return
 128 copies of `é` is 256 bytes and is refused despite having only 128
 characters. The new character checks do not remove these byte guards.
 
-Native Server 3.8.0 does not consistently validate these command-name bounds
-before writes. SQLite can silently store over-long names; other backends can
-return database errors. The [source correction](https://github.com/durable-workflow/server/pull/1186)
-adds field-specific `422` refusals before writes, such as
-`commands.0.activity_type`, but awaits a qualified published Server release.
-The selected stable remains 3.8.0. Review existing activity types and signal
-waits longer than 191 characters before upgrading to that corrected release:
-new commands using those names will be refused. The remaining identifier
-sweep is tracked in [Server #607](https://github.com/durable-workflow/server/issues/607).
+Native Server 3.9.1 includes the [published correction](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes):
+field-specific `422 validation_failed` refusals, such as
+`commands.0.activity_type`, before writes. Native 3.8.0 did not consistently
+validate these character bounds; SQLite could silently store over-long names
+while other backends could return database errors. Review existing activity
+types and signal waits longer than 191 characters before upgrading: new
+commands using those names are now refused. The remaining identifier sweep is
+tracked in [Server #607](https://github.com/durable-workflow/server/issues/607).
 The 256-byte HTTP operation-name ceiling above is a separate boundary.
 
 ### Workflow-task completion size {#workflow-task-completion-size}
@@ -434,6 +433,14 @@ still meet the per-payload limit inside the completion. PHP Server 2.x and
 earlier native releases cap a completion at one payload limit, like any other
 request.
 
+Native 3.9.1 advertises the actual positive integer budget as
+`limits.max_workflow_task_completion_bytes` in cluster info. It measures the
+complete encoded JSON request body, including envelopes, metadata and commands,
+for both completion routes. Use that advertised value rather than inferring a
+multiplier from the Server version or summing decoded arguments. Per-value and
+ordinary-route limits remain unchanged. The field grants no additional external
+payload upload or reference-placement authority.
+
 A larger completion is refused with `413 payload_too_large` and
 `limit_kind: workflow_task_completion_bytes` before anything is recorded.
 Replaying the task produces the same commands, so sending the completion again
@@ -444,19 +451,22 @@ sizes, and the Server records the failure with
 `failure_category = structural_limit`.
 
 Python SDK 2.17 and Rust SDK 4.15 include handling for the typed refusal.
-On Server 3.8.0, an oversized completion can fail at the transport before the
-worker receives HTTP 413. In the published Python test, `httpx.ReadError` left
-the workflow pending instead of failing structurally. Published-Server
-over-limit acceptance remains open under the
-[Server response fix](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678).
-Reduce completion sizes until that path is qualified.
+On Server 3.8.0, a published Python control hit `httpx.ReadError` before receiving
+HTTP 413 and left the workflow pending. Native 3.9.1 corrects that response
+path with bounded request discard: at most 64 MiB of remaining upload data for
+at most two seconds before returning the original refusal and closing the
+connection. Uploads beyond either bound may still encounter transport errors.
+Actual installed-SDK within-cap, over-cap and same-worker follow-up acceptance
+remains separately tracked in [shared #228](https://github.com/durable-workflow/.github/issues/228).
+Server publication alone does not qualify those SDK paths.
 
 To keep a completion within the limit:
 
 - Split a large fan-out into smaller batches across workflow tasks.
 - Move work into child workflows, or continue as new.
-- Store large arguments with external payload storage, so the completion
-  carries references instead of the payloads.
+- Use external payload storage only for supported payload placements.
+  Activity-continuation command arguments remain inline; an activity/result
+  upload allowance does not authorize references in those command arguments.
 
 #### Rust command planning {#rust-completion-planning}
 
diff --git a/docs/polyglot/server.md b/docs/polyglot/server.md
index de1e8ae93f4..af2ab309bee 100644
--- a/docs/polyglot/server.md
+++ b/docs/polyglot/server.md
@@ -175,6 +175,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 The stack is the native Server and MySQL. Compose refuses to start until
 `DW_AUTH_TOKEN` is set. The [deployment guide](/docs/deployment#single-node-production)
 covers the production env file, backups and upgrades.
+Upgrades from native 3.8.x or earlier to 3.9.1 require the
+[explicit schema upgrade](../deployment.md#native-schema-upgrade-3-9) before restart.
 
 ### Ports
 

From b9082b887e18f802d3b925d9e737caccee354ff2 Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:05:49 +0000
Subject: [PATCH 2/6] State completion discovery refusal and fallback semantics

---
 docs/polyglot/server-config-reference.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index a15d70755b4..9b345866709 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -433,7 +433,7 @@ still meet the per-payload limit inside the completion. PHP Server 2.x and
 earlier native releases cap a completion at one payload limit, like any other
 request.
 
-Native 3.9.1 advertises the actual positive integer budget as
+Native 3.9.1 advertises the actual budget as
 `limits.max_workflow_task_completion_bytes` in cluster info. It measures the
 complete encoded JSON request body, including envelopes, metadata and commands,
 for both completion routes. Use that advertised value rather than inferring a
@@ -441,6 +441,11 @@ multiplier from the Server version or summing decoded arguments. Per-value and
 ordinary-route limits remain unchanged. The field grants no additional external
 payload upload or reference-placement authority.
 
+SDK planners must honor a positive advertised cap even below the ordinary
+limit. An absent field preserves the conservative fallback; an explicitly
+malformed, null, zero, negative or non-integer value refuses completion planning
+before upload. Ordinary routes ignore this unused completion field.
+
 A larger completion is refused with `413 payload_too_large` and
 `limit_kind: workflow_task_completion_bytes` before anything is recorded.
 Replaying the task produces the same commands, so sending the completion again

From 40b196c11eb338e3242d954429eeed1de4874909 Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:08:43 +0000
Subject: [PATCH 3/6] Record qualified Python completion acceptance on native
 3.9.1

---
 docs/polyglot/server-config-reference.md | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index 9b345866709..ab178e27605 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -461,9 +461,13 @@ HTTP 413 and left the workflow pending. Native 3.9.1 corrects that response
 path with bounded request discard: at most 64 MiB of remaining upload data for
 at most two seconds before returning the original refusal and closing the
 connection. Uploads beyond either bound may still encounter transport errors.
-Actual installed-SDK within-cap, over-cap and same-worker follow-up acceptance
-remains separately tracked in [shared #228](https://github.com/durable-workflow/.github/issues/228).
-Server publication alone does not qualify those SDK paths.
+Published Python SDK 2.17.1 with qualified native Server 3.9.1 now passes the
+[actual installed-worker controls](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512):
+300 × 10 KB within-cap fan-out, one typed 413 and one structural failure with
+zero partial activities for an oversized completion, then a successful task on
+the same worker. This qualifies that exact Python/Server tuple. PHP and Rust
+require their own installed acceptance; shared #228 remains open. Request-key
+acceptance under shared #216 is separate.
 
 To keep a completion within the limit:
 

From 9182e0d5337ab40a47cb2ba3c501e38cac4f99b8 Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:26:13 +0000
Subject: [PATCH 4/6] Translate Server 3.9.1 upgrade and qualified completion
 guidance

---
 docs/polyglot/server-config-reference.md      |  9 ++++-
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 32 +++++++-----------
 .../current/polyglot/server.md                |  2 ++
 i18n/de/source-hashes.json                    |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 33 +++++++------------
 .../current/polyglot/server.md                |  2 ++
 i18n/es/source-hashes.json                    |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 32 +++++++-----------
 .../current/polyglot/server.md                |  2 ++
 i18n/fr/source-hashes.json                    |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 16 ++++++---
 .../current/polyglot/server.md                |  2 ++
 i18n/ja/source-hashes.json                    |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 32 +++++++-----------
 .../current/polyglot/server.md                |  2 ++
 i18n/pt-BR/source-hashes.json                 |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 31 +++++++----------
 .../current/polyglot/server.md                |  2 ++
 i18n/uk/source-hashes.json                    |  6 ++--
 .../current/deployment.md                     | 15 +++++++++
 .../polyglot/server-config-reference.md       | 16 ++++++---
 .../current/polyglot/server.md                |  2 ++
 i18n/zh-Hans/source-hashes.json               |  6 ++--
 29 files changed, 232 insertions(+), 130 deletions(-)

diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index ab178e27605..d8556ba8229 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -367,6 +367,12 @@ listed in its [implementation notes](#native-server-3x). On native 3.8.0,
 workflow-task completions, rejecting nonempty bodies. Its operation-name
 ceiling is fixed at 256 bytes.
 
+Native 3.9.1 still applies a 255-byte UTF-8 check to signal `request_id`.
+A 255-character multibyte key can therefore return `422 invalid_request_id`.
+The [installed CLI qualification](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056)
+tracks this published limitation; it does not establish full request-key
+acceptance under shared #216.
+
 The currently-configured values are published under `limits` on the `GET /api/cluster/info` response, so clients can discover them at runtime:
 
 ```json
@@ -461,7 +467,8 @@ HTTP 413 and left the workflow pending. Native 3.9.1 corrects that response
 path with bounded request discard: at most 64 MiB of remaining upload data for
 at most two seconds before returning the original refusal and closing the
 connection. Uploads beyond either bound may still encounter transport errors.
-Published Python SDK 2.17.1 with qualified native Server 3.9.1 now passes the
+Published Python SDK 2.17.1 with qualified native Server 3.9.1
+(linux/amd64, SQLite) now passes the
 [actual installed-worker controls](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512):
 300 × 10 KB within-cap fan-out, one typed 413 and one structural failure with
 zero partial activities for an oversized completion, then a successful task on
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
index c6bd457892d..394e125ca98 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/deployment.md
@@ -195,6 +195,21 @@ 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.9.1 {#native-schema-upgrade-3-9}
+
+Ein Upgrade von native 3.8.x oder früher erfordert auf jedem Backend ein Schema-Upgrade. Server 3.9.1 fügt die leere Tabelle `dw_command_intents` hinzu:
+
+| Backend | Schemaübergang von 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Stoppen Sie alle Server-Replikate, lassen Sie die Datenbank laufen, sichern Sie Datenbank und Server-Speicher und wählen und laden Sie dann das Image 3.9.1. Führen Sie dessen `schema-upgrade` einmal aus, bevor alle Replikate auf derselben Version neu starten. Server aktualisiert ein vorhandenes Schema nicht beim Start: Ein altes Schema wird mit `native_schema_upgrade_required` abgelehnt. Prüfen Sie danach Readiness, gemeldete Version und Worker-Registrierung. Die [qualifizierte Release-Anleitung für 3.9.1](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade) enthält die Compose-Befehle ohne Quellcode-Checkout.
+
+MySQL und MariaDB setzen unterbrochene Upgrades fort; SQLite und PostgreSQL führen den Schritt transaktional aus. Ein Rollback auf 3.8.x erfordert das Backup: 3.8.0 lehnt die aktualisierte Datenbank mit `native_schema_newer_than_binary` ab. Von 3.9.0 ist kein weiterer Schemaschritt nötig. Von älteren Versionen führt `schema-upgrade` auch die vorherigen Schritte aus, gegebenenfalls einschließlich des [JSON-Neuaufbaus aus 3.7](#native-schema-upgrade-3-7). Worker-Protokoll 1.20 und Control Plane 2 bleiben unverändert.
+
 ### Upgrade auf Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 benötigt auf jedem Backend ein natives Schema-Upgrade. Es fügt eine nur native Tabelle hinzu, `dw_task_queue_pauses`, die leer angelegt wird:
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 779f7b3fe54..9e0b3756ee0 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -293,6 +293,8 @@ Grenze für gewöhnliche Anfragen und Workflow-Task-Completions auf null Bytes,
 sodass nichtleere Bodys abgelehnt werden. Die Grenze für Operationsnamen ist
 fest auf 256 Bytes gesetzt.
 
+Native 3.9.1 prüft Signal-`request_id` weiterhin gegen 255 UTF-8-Bytes. Ein mehrbyteiger Schlüssel mit 255 Zeichen kann daher `422 invalid_request_id` auslösen. Die [Qualifikation der installierten CLI](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056) verfolgt diese veröffentlichte Einschränkung; sie belegt keine vollständige Request-Key-Akzeptanz unter dem gemeinsamen #216.
+
 Die aktuell konfigurierten Werte werden unter `limits` in der Antwort von
 `GET /api/cluster/info` veröffentlicht. Clients können sie dadurch zur Laufzeit
 ermitteln:
@@ -335,8 +337,7 @@ separate Start-API; Felder von Child-Aufrufen haben engere Grenzen als andere Be
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-Native 3.8.0 und der korrigierte Quellcode behalten außerdem UTF-8-Byte-Prüfungen
-bei. Für `activity_type`, `open_signal_wait.signal_name`, eine explizite
+Native 3.8.0 und 3.9.1 behalten außerdem UTF-8-Byte-Prüfungen bei. Für `activity_type`, `open_signal_wait.signal_name`, eine explizite
 `schedule_activity.queue` und `continue_as_new.workflow_type` / `queue`
 gilt eine Parsergrenze von 255 Bytes (`422 invalid_request`). Für Child-
 `workflow_type` und `queue` gilt zusätzlich eine 191-Byte-Prüfung, die
@@ -344,36 +345,27 @@ gilt eine Parsergrenze von 255 Bytes (`422 invalid_request`). Für Child-
 128 Wiederholungen von `é` hat beispielsweise 256 Bytes und wird trotz nur
 128 Zeichen abgelehnt. Die neuen Zeichenprüfungen heben diese Byte-Prüfungen nicht auf.
 
-Native Server 3.8.0 prüft diese Namensgrenzen vor Schreibvorgängen nicht
-konsistent. SQLite kann überlange Namen stillschweigend speichern; andere
-Backends können Datenbankfehler zurückgeben. Die [Quellcodekorrektur](https://github.com/durable-workflow/server/pull/1186)
-fügt vor Schreibvorgängen feldspezifische `422`-Ablehnungen hinzu, etwa für
-`commands.0.activity_type`, wartet aber noch auf eine qualifizierte
-veröffentlichte Server-Version. Die ausgewählte stabile Version bleibt 3.8.0.
-Prüfen Sie vor dem Upgrade auf die korrigierte Version vorhandene Activity-Typen
-und Signal-Waits mit Namen über 191 Zeichen: Neue Befehle mit diesen Namen
-werden abgelehnt. Die übrige Kennungsprüfung wird in [Server #607](https://github.com/durable-workflow/server/issues/607)
-verfolgt. Die obige HTTP-Grenze von 256 Bytes für Operationsnamen ist separat.
+Native Server 3.9.1 enthält die [veröffentlichte Korrektur](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes): feldspezifische `422 validation_failed`-Ablehnungen, etwa für `commands.0.activity_type`, vor Schreibvorgängen. Native 3.8.0 prüfte diese Zeichengrenzen nicht konsistent; SQLite konnte überlange Namen stillschweigend speichern, während andere Backends Datenbankfehler zurückgaben. Prüfen Sie vor dem Upgrade vorhandene Activity-Typen und Signal-Waits mit Namen über 191 Zeichen: Neue Befehle mit diesen Namen werden nun abgelehnt. Die übrige Kennungsprüfung wird in [Server #607](https://github.com/durable-workflow/server/issues/607) verfolgt. Die obige HTTP-Grenze von 256 Bytes für Operationsnamen ist separat.
 
 ### Größe eines Workflow-Task-Abschlusses {#workflow-task-completion-size}
 
 Auf nativem Server 3.6.0 und neuer darf eine Anfrage, die einen Workflow-Task mit Befehlen abschließt (`POST /api/worker/workflow-tasks/{id}/complete` und `POST /api/worker/activity-tasks/{id}/continuation/complete`), bis zum 16-Fachen von `max_payload_bytes` groß sein: 32 MiB beim Standardwert von 2 MiB. Sie folgt `DW_MAX_PAYLOAD_BYTES` und hat keine eigene Einstellung. Die Argumente jedes Befehls müssen innerhalb des Abschlusses weiterhin die Grenze pro Payload einhalten. PHP-Server 2.x und frühere native Versionen begrenzen einen Abschluss wie jede andere Anfrage auf eine Payload-Grenze.
 
+Native 3.9.1 veröffentlicht das tatsächliche Budget als `limits.max_workflow_task_completion_bytes` in Cluster-Info. Es misst für beide Completion-Routen den vollständig kodierten JSON-Anfragekörper einschließlich Envelopes, Metadaten und Befehlen. Verwenden Sie diesen Wert, statt einen Multiplikator aus der Server-Version abzuleiten oder dekodierte Argumentgrößen zu addieren. Die Grenzen pro Wert und für gewöhnliche Routen bleiben unverändert. Das Feld erteilt keine zusätzliche Berechtigung zum Hochladen externer Payloads oder Platzieren von Referenzen.
+
+SDK-Planer müssen eine positive veröffentlichte Grenze auch unterhalb der gewöhnlichen Grenze beachten. Fehlt das Feld, bleibt der konservative Fallback erhalten. Ein explizit fehlerhafter Wert, ein Nullwert (null), die Zahl Null, ein negativer oder nicht ganzzahliger Wert verweigert die Completion-Planung vor dem Upload. Gewöhnliche Routen ignorieren dieses ungenutzte Completion-Feld.
+
 Ein größerer Abschluss wird mit `413 payload_too_large` und `limit_kind: workflow_task_completion_bytes` abgelehnt, bevor etwas aufgezeichnet wird. Eine erneute Ausführung des Tasks erzeugt dieselben Befehle, daher führt erneutes Senden zur selben Ablehnung. Erhält PHP SDK 3.17.0 oder neuer diese typisierte Ablehnung, sendet es die Completion nicht erneut: Der Worker lässt den Lauf einmal mit einem `fail_workflow`-Befehl fehlschlagen, dessen Nachricht mit `Structural limit exceeded: workflow_task_completion_bytes:` beginnt und beide Größen nennt, und der Server zeichnet den Fehler mit `failure_category = structural_limit` auf.
 
-Python SDK 2.17 und Rust SDK 4.15 behandeln die typisierte Ablehnung. Bei
-Server 3.8.0 kann eine zu große Completion bereits beim Transport scheitern,
-bevor der Worker HTTP 413 erhält. Im Test mit dem veröffentlichten Python-SDK
-ließ `httpx.ReadError` den Workflow ausstehend, statt ihn strukturell scheitern
-zu lassen. Die Qualifikation übergroßer Anfragen am veröffentlichten Server ist
-unter der [Korrektur der Server-Antwort](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678)
-weiter offen. Verkleinern Sie die Completions, bis dieser Pfad qualifiziert ist.
+Python SDK 2.17 und Rust SDK 4.15 behandeln die typisierte Ablehnung. Auf Server 3.8.0 traf ein veröffentlichter Python-Kontrolllauf vor HTTP 413 auf `httpx.ReadError` und ließ den Workflow offen. Native 3.9.1 korrigiert diesen Antwortpfad durch begrenztes Verwerfen der Anfrage: höchstens 64 MiB verbleibende Upload-Daten und höchstens zwei Sekunden, bevor die ursprüngliche Ablehnung zurückgegeben und die Verbindung geschlossen wird. Außerhalb dieser Grenzen können weiterhin Transportfehler auftreten.
+
+Das veröffentlichte Python SDK 2.17.1 mit qualifiziertem nativem Server 3.9.1 (linux/amd64, SQLite) besteht nun die [Kontrollen mit tatsächlich installiertem Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): Fan-out von 300 × 10 KB innerhalb der Grenze, genau ein typisiertes 413 und ein struktureller Fehler ohne teilweise gestartete Aktivitäten bei übergroßer Completion, danach eine erfolgreiche Aufgabe auf demselben Worker. Dies qualifiziert genau dieses Python/Server-Paar. PHP und Rust benötigen eigene installierte Akzeptanznachweise; das gemeinsame #228 bleibt offen. Die Request-Key-Akzeptanz unter dem gemeinsamen #216 ist separat.
 
 So bleibt ein Abschluss innerhalb der Grenze:
 
 - Teilen Sie ein großes Fan-out in kleinere Stapel über mehrere Workflow-Tasks auf.
 - Verlagern Sie Arbeit in Child-Workflows, oder verwenden Sie Continue-as-New.
-- Speichern Sie große Argumente im externen Payload-Speicher, sodass der Abschluss Referenzen statt der Payloads enthält.
+- Verwenden Sie externen Payload-Speicher nur für unterstützte Payload-Positionen. Befehlsargumente einer Activity-Continuation bleiben inline; eine Upload-Berechtigung für Activity oder Ergebnis erlaubt dort keine Referenzen.
 
 #### Rust-Befehlsplanung {#rust-completion-planning}
 
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 af797c23c44..79ccdfc91ae 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -135,6 +135,8 @@ Der Stack besteht aus dem nativen Server und MySQL. Compose verweigert den Start
 `DW_AUTH_TOKEN` nicht gesetzt ist. Der [Bereitstellungsleitfaden](/docs/deployment#single-node-production)
 behandelt die Produktions-Env-Datei, Sicherungen und Upgrades.
 
+Upgrades von native 3.8.x oder früher auf 3.9.1 benötigen vor dem Neustart das [explizite Schema-Upgrade](../deployment.md#native-schema-upgrade-3-9).
+
 ### Ports {#ports}
 
 | Dienst | Port | Zweck |
diff --git a/i18n/de/source-hashes.json b/i18n/de/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 d872164ea19..888d6f10da0 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/deployment.md
@@ -263,6 +263,21 @@ 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.9.1 {#native-schema-upgrade-3-9}
+
+Actualizar desde native 3.8.x o anterior exige actualizar el esquema en todos los backends. Server 3.9.1 añade la tabla vacía `dw_command_intents`:
+
+| Backend | Transición del esquema desde 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Detenga todas las réplicas del Server, mantenga la base de datos en ejecución, haga copia de la base de datos y del almacenamiento del Server, y seleccione y descargue la imagen 3.9.1. Ejecute una vez su `schema-upgrade` antes de reiniciar todas las réplicas con la misma versión. Server no actualiza un esquema existente al arrancar: rechaza el antiguo con `native_schema_upgrade_required`. Compruebe readiness, versión y registro del Worker después del reinicio. Las [instrucciones cualificadas de la versión 3.9.1](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade) incluyen los comandos Compose sin checkout del código fuente.
+
+MySQL y MariaDB reanudan las actualizaciones interrumpidas; SQLite y PostgreSQL aplican el paso en una transacción. Volver a 3.8.x requiere restaurar la copia: 3.8.0 rechaza la base actualizada con `native_schema_newer_than_binary`. Desde 3.9.0 no hace falta otro paso de esquema. Desde versiones anteriores, `schema-upgrade` aplica también los pasos previos, incluida la [reconstrucción JSON de 3.7](#native-schema-upgrade-3-7) cuando corresponda. El protocolo de workers 1.20 y el plano de control 2 no cambian.
+
 ### Actualizar a Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 necesita una actualización de esquema native en todos los backends. Añade una tabla exclusiva de native, `dw_task_queue_pauses`, que se crea vacía:
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 188e8a285bd..c20841ecb82 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -287,6 +287,8 @@ En native 3.8.0, `DW_MAX_PAYLOAD_BYTES=0` establece un techo de cero bytes para
 solicitudes normales y finalizaciones de tareas de workflow, rechazando
 cuerpos no vacíos. El límite de nombres de operación es fijo: 256 bytes.
 
+El runtime nativo 3.9.1 sigue comprobando `request_id` de señales contra 255 bytes UTF-8. Una clave multibyte de 255 caracteres puede devolver `422 invalid_request_id`. La [cualificación de la CLI instalada](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056) registra esta limitación publicada; no establece aceptación completa de claves de solicitud bajo el #216 compartido.
+
 Los valores configurados actualmente se publican bajo `limits` en la respuesta de `GET /api/cluster/info`, de modo que los clientes pueden descubrirlos durante la ejecución:
 
 ```json
@@ -324,8 +326,7 @@ llamadas a hijos tienen límites más estrictos que otros comandos.
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-El runtime nativo 3.8.0 y el código corregido conservan comprobaciones de bytes
-UTF-8. `activity_type`, `open_signal_wait.signal_name`, una
+Los runtimes nativos 3.8.0 y 3.9.1 conservan comprobaciones de bytes UTF-8. `activity_type`, `open_signal_wait.signal_name`, una
 `schedule_activity.queue` explícita y `continue_as_new.workflow_type` / `queue`
 tienen un límite de análisis de 255 bytes (`422 invalid_request`). Los campos
 `workflow_type` y `queue` de un hijo tienen además un límite de 191 bytes que
@@ -333,37 +334,27 @@ puede devolver `422 unsupported_child_options`. Por ejemplo, un tipo de
 actividad con 128 copias de `é` ocupa 256 bytes y se rechaza aunque solo tenga
 128 caracteres. Las nuevas comprobaciones de caracteres no eliminan estos límites de bytes.
 
-El Server nativo 3.8.0 no valida estos límites de nombres de forma uniforme
-antes de escribir. SQLite puede almacenar nombres demasiado largos sin avisar;
-otros backends pueden devolver errores de base de datos. La [corrección del código](https://github.com/durable-workflow/server/pull/1186)
-añade rechazos `422` específicos del campo antes de escribir, como
-`commands.0.activity_type`, pero aún espera una versión publicada y cualificada
-del Server. La versión estable seleccionada sigue siendo 3.8.0. Antes de
-actualizar a esa versión corregida, revise los tipos de actividad y las esperas
-de señales existentes con nombres de más de 191 caracteres: los nuevos comandos
-con esos nombres se rechazarán. La revisión de los demás identificadores se
-sigue en [Server #607](https://github.com/durable-workflow/server/issues/607).
-El límite HTTP anterior de 256 bytes para nombres de operaciones es independiente.
+El Server nativo 3.9.1 incluye la [corrección publicada](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes): rechazos `422 validation_failed` específicos del campo, como `commands.0.activity_type`, antes de escribir. El runtime nativo 3.8.0 no validaba estos límites de caracteres de forma uniforme; SQLite podía guardar nombres demasiado largos sin avisar, mientras otros backends devolvían errores de base de datos. Antes de actualizar, revise tipos de actividad y esperas de señales con nombres de más de 191 caracteres: ahora los comandos nuevos con esos nombres se rechazan. La revisión de los demás identificadores sigue en [Server #607](https://github.com/durable-workflow/server/issues/607). El límite HTTP anterior de 256 bytes para nombres de operaciones es independiente.
 
 ### Tamaño de finalización de tarea de workflow {#workflow-task-completion-size}
 
 En el Server nativo 3.6.0 y posteriores, una solicitud que finaliza una tarea de workflow con comandos (`POST /api/worker/workflow-tasks/{id}/complete` y `POST /api/worker/activity-tasks/{id}/continuation/complete`) puede ocupar hasta 16 veces `max_payload_bytes`: 32 MiB con el valor predeterminado de 2 MiB. Sigue a `DW_MAX_PAYLOAD_BYTES` y no tiene un ajuste propio. Los argumentos de cada comando siguen respetando el límite por carga útil dentro de la finalización. El Server PHP 2.x y las versiones nativas anteriores limitan una finalización a un límite de carga útil, como cualquier otra solicitud.
 
+El runtime nativo 3.9.1 publica el presupuesto real como `limits.max_workflow_task_completion_bytes` en cluster info. Mide el cuerpo JSON codificado completo de la solicitud, incluidos envelopes, metadatos y comandos, para ambas rutas de finalización. Use ese valor en vez de inferir un multiplicador a partir de la versión o sumar argumentos decodificados. Los límites por valor y de rutas ordinarias no cambian. El campo no concede permisos adicionales de subida de payloads externos ni de colocación de referencias.
+
+Los planificadores de los SDK deben respetar un límite positivo publicado incluso si es menor que el ordinario. Si el campo falta, se conserva el fallback conservador; un valor explícitamente mal formado, nulo, cero, negativo o no entero rechaza la planificación antes de subir datos. Las rutas ordinarias ignoran este campo de finalización no utilizado.
+
 Una finalización mayor se rechaza con `413 payload_too_large` y `limit_kind: workflow_task_completion_bytes` antes de registrar nada. Reproducir la tarea genera los mismos comandos, así que reenviar la finalización recibe el mismo rechazo. Cuando PHP SDK 3.17.0 o posterior recibe este rechazo tipado, no reenvía la finalización: el worker hace fallar la ejecución una sola vez con un comando `fail_workflow` cuyo mensaje empieza por `Structural limit exceeded: workflow_task_completion_bytes:` e indica ambos tamaños, y el Server registra el fallo con `failure_category = structural_limit`.
 
-Python SDK 2.17 y Rust SDK 4.15 gestionan el rechazo tipado. En Server 3.8.0,
-una finalización demasiado grande puede fallar en el transporte antes de que el
-worker reciba HTTP 413. En la prueba con el SDK de Python publicado,
-`httpx.ReadError` dejó el workflow pendiente en lugar de fallar por un límite
-estructural. La aceptación de solicitudes sobredimensionadas en el Server
-publicado sigue abierta en la [corrección de la respuesta del Server](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678).
-Reduzca las finalizaciones hasta que esa ruta esté cualificada.
+Python SDK 2.17 y Rust SDK 4.15 incluyen el manejo del rechazo tipado. En Server 3.8.0, un control publicado de Python obtuvo `httpx.ReadError` antes de recibir HTTP 413 y dejó el workflow pendiente. El runtime nativo 3.9.1 corrige esa respuesta descartando datos de forma acotada: como máximo 64 MiB de la subida restante durante dos segundos, antes de devolver el rechazo original y cerrar la conexión. Las subidas que superen cualquiera de esos límites aún pueden sufrir errores de transporte.
+
+Python SDK 2.17.1 publicado con Server nativo 3.9.1 cualificado (linux/amd64, SQLite) supera ahora los [controles con el Worker instalado real](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro del límite, un único 413 tipado y un único fallo estructural sin actividades parciales para una finalización sobredimensionada, y después una tarea correcta en el mismo Worker. Esto cualifica ese par exacto Python/Server. PHP y Rust requieren su propia aceptación instalada; el #228 compartido sigue abierto. La aceptación de claves de solicitud del #216 compartido es independiente.
 
 Para mantener una finalización dentro del límite:
 
 - Divida un fan-out grande en lotes más pequeños repartidos entre tareas de workflow.
 - Mueva trabajo a workflows hijos, o use continue-as-new.
-- Guarde los argumentos grandes en el almacenamiento externo de cargas útiles, para que la finalización lleve referencias en lugar de las cargas útiles.
+- Use almacenamiento externo de payloads solo para ubicaciones admitidas. Los argumentos de comandos de continuación de actividades siguen inline; un permiso de subida de actividad/resultado no autoriza referencias en esos argumentos.
 
 #### Planificación de comandos en Rust {#rust-completion-planning}
 
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 f851a132803..f5035532f35 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -124,6 +124,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 
 El conjunto contiene el Server nativo y MySQL. Compose se niega a arrancar hasta que se defina `DW_AUTH_TOKEN`. La [guía de despliegue](/docs/deployment#single-node-production) cubre el archivo de entorno de producción, las copias de seguridad y las actualizaciones.
 
+Actualizar desde native 3.8.x o anterior a 3.9.1 exige la [actualización explícita del esquema](../deployment.md#native-schema-upgrade-3-9) antes de reiniciar.
+
 ### Puertos {#ports}
 
 | Servicio | Puerto | Propósito |
diff --git a/i18n/es/source-hashes.json b/i18n/es/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 a6af60fdc54..8156a5b5d74 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/deployment.md
@@ -269,6 +269,21 @@ 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).
 
+### Mise à niveau vers Server 3.9.1 {#native-schema-upgrade-3-9}
+
+Passer de native 3.8.x ou antérieur exige une mise à niveau du schéma sur chaque backend. Server 3.9.1 ajoute la table vide `dw_command_intents` :
+
+| Backend | Transition du schéma depuis 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Arrêtez toutes les répliques du Server, laissez tourner la base de données, sauvegardez la base et le stockage du Server, puis sélectionnez et téléchargez l’image 3.9.1. Exécutez son `schema-upgrade` une fois avant de redémarrer toutes les répliques sur la même version. Server ne met pas à niveau un schéma existant au démarrage : il refuse l’ancien avec `native_schema_upgrade_required`. Vérifiez readiness, version et enregistrement du Worker après redémarrage. Les [instructions qualifiées de la version 3.9.1](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade) fournissent les commandes Compose sans checkout des sources.
+
+MySQL et MariaDB reprennent une mise à niveau interrompue ; SQLite et PostgreSQL appliquent l’étape dans une transaction. Revenir à 3.8.x exige de restaurer la sauvegarde : 3.8.0 refuse la base mise à niveau avec `native_schema_newer_than_binary`. Depuis 3.9.0, aucune étape de schéma supplémentaire n’est nécessaire. Depuis une version plus ancienne, `schema-upgrade` applique aussi les étapes antérieures, y compris la [reconstruction JSON de 3.7](#native-schema-upgrade-3-7) si nécessaire. Le protocole Worker 1.20 et le plan de contrôle 2 restent inchangés.
+
 ### Mettre à niveau vers Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 nécessite une mise à niveau du schéma native sur chaque backend. Il ajoute une table propre à native, `dw_task_queue_pauses`, créée vide :
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index b41679b20c0..0bdb959c1c1 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -287,6 +287,8 @@ Sur native 3.8.0, `DW_MAX_PAYLOAD_BYTES=0` fixe un plafond de zéro octet pour
 les requêtes ordinaires et les complétions de tâches de workflow, refusant les
 corps non vides. Le plafond des noms d'opérations est fixé à 256 octets.
 
+Le runtime natif 3.9.1 vérifie encore le `request_id` des signaux contre 255 octets UTF-8. Une clé multioctet de 255 caractères peut donc renvoyer `422 invalid_request_id`. La [qualification de la CLI installée](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056) suit cette limite publiée ; elle ne prouve pas l’acceptation complète des clés de requête du #216 partagé.
+
 Les valeurs actuellement configurées sont publiées sous `limits` dans la réponse de `GET /api/cluster/info`, pour permettre leur découverte par les clients :
 
 ```json
@@ -324,8 +326,7 @@ appels enfants ont des limites plus strictes que les autres commandes.
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-Le runtime natif 3.8.0 et le code corrigé conservent aussi des contrôles
-d’octets UTF-8. `activity_type`, `open_signal_wait.signal_name`, une
+Les runtimes natifs 3.8.0 et 3.9.1 conservent aussi des contrôles d’octets UTF-8. `activity_type`, `open_signal_wait.signal_name`, une
 `schedule_activity.queue` explicite et `continue_as_new.workflow_type` / `queue`
 ont un plafond d’analyse de 255 octets (`422 invalid_request`). Les champs
 `workflow_type` et `queue` d’un enfant ont un contrôle supplémentaire de
@@ -333,36 +334,27 @@ ont un plafond d’analyse de 255 octets (`422 invalid_request`). Les champs
 type d’activité contenant 128 copies de `é` occupe 256 octets et est refusé
 malgré ses 128 caractères. Les nouveaux contrôles de caractères ne suppriment pas ces contrôles d’octets.
 
-Le Server natif 3.8.0 ne valide pas systématiquement ces limites de noms avant
-les écritures. SQLite peut stocker silencieusement des noms trop longs ; les
-autres backends peuvent renvoyer des erreurs de base de données. La [correction du code](https://github.com/durable-workflow/server/pull/1186)
-ajoute des refus `422` propres à chaque champ avant toute écriture, par exemple
-`commands.0.activity_type`, mais attend encore une version publiée et qualifiée
-du Server. La version stable sélectionnée reste 3.8.0. Avant de passer à cette
-version corrigée, vérifiez les types d’activité et les attentes de signal dont
-les noms dépassent 191 caractères : les nouvelles commandes utilisant ces noms
-seront refusées. L’examen des autres identifiants est suivi dans [Server #607](https://github.com/durable-workflow/server/issues/607).
-Le plafond HTTP de 256 octets pour les noms d’opérations ci-dessus est distinct.
+Le Server natif 3.9.1 inclut la [correction publiée](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes) : des refus `422 validation_failed` propres aux champs, comme `commands.0.activity_type`, avant les écritures. Le runtime natif 3.8.0 ne validait pas systématiquement ces limites de caractères ; SQLite pouvait stocker silencieusement des noms trop longs, tandis que d’autres backends renvoyaient des erreurs de base de données. Avant la mise à niveau, vérifiez les types d’activité et les attentes de signal dont les noms dépassent 191 caractères : les nouvelles commandes avec ces noms sont désormais refusées. L’examen des autres identifiants reste suivi dans [Server #607](https://github.com/durable-workflow/server/issues/607). Le plafond HTTP de 256 octets pour les noms d’opérations ci-dessus est distinct.
 
 ### Taille d’un achèvement de tâche de workflow {#workflow-task-completion-size}
 
 Sur Server natif 3.6.0 et ultérieur, une requête qui achève une tâche de workflow avec des commandes (`POST /api/worker/workflow-tasks/{id}/complete` et `POST /api/worker/activity-tasks/{id}/continuation/complete`) peut atteindre 16 fois `max_payload_bytes` : 32 MiB avec la valeur par défaut de 2 MiB. Elle suit `DW_MAX_PAYLOAD_BYTES` et n’a pas de réglage propre. Les arguments de chaque commande respectent toujours la limite par payload à l’intérieur de l’achèvement. Server PHP 2.x et les versions natives antérieures limitent un achèvement à une limite de payload, comme toute autre requête.
 
+Le runtime natif 3.9.1 publie le budget réel dans `limits.max_workflow_task_completion_bytes` via cluster info. Il mesure le corps JSON encodé complet, avec les enveloppes, métadonnées et commandes, pour les deux routes de finalisation. Utilisez cette valeur au lieu de déduire un multiplicateur de la version ou d’additionner les arguments décodés. Les limites par valeur et des routes ordinaires restent inchangées. Ce champ n’accorde aucune autorisation supplémentaire de téléversement de payloads externes ou de placement de références.
+
+Les planificateurs des SDK doivent respecter un plafond positif publié même inférieur à la limite ordinaire. L’absence du champ conserve le repli conservateur ; une valeur explicite mal formée, nulle, zéro, négative ou non entière refuse la planification avant le téléversement. Les routes ordinaires ignorent ce champ de finalisation inutilisé.
+
 Un achèvement plus grand est refusé avec `413 payload_too_large` et `limit_kind: workflow_task_completion_bytes` avant tout enregistrement. Rejouer la tâche produit les mêmes commandes : renvoyer l’achèvement obtient donc le même refus. Lorsque PHP SDK 3.17.0 ou ultérieur reçoit ce refus typé, il ne renvoie pas cet achèvement : le worker fait échouer l’exécution une seule fois avec une commande `fail_workflow` dont le message commence par `Structural limit exceeded: workflow_task_completion_bytes:` et indique les deux tailles, et le Server enregistre l’échec avec `failure_category = structural_limit`.
 
-Python SDK 2.17 et Rust SDK 4.15 gèrent le refus typé. Sur Server 3.8.0, une
-complétion trop volumineuse peut échouer au niveau du transport avant que le
-worker reçoive HTTP 413. Dans le test avec le SDK Python publié,
-`httpx.ReadError` a laissé le workflow en attente au lieu d'un échec pour limite
-structurelle. La qualification des requêtes surdimensionnées sur le Server
-publié reste ouverte dans la [correction de la réponse du Server](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678).
-Réduisez les complétions jusqu'à la qualification de ce chemin.
+Python SDK 2.17 et Rust SDK 4.15 gèrent le refus typé. Sur Server 3.8.0, un contrôle Python publié rencontrait `httpx.ReadError` avant HTTP 413 et laissait le workflow en attente. Le runtime natif 3.9.1 corrige cette réponse par une lecture puis un abandon bornés du reste de la requête : au plus 64 MiB pendant deux secondes avant de renvoyer le refus original et fermer la connexion. Au-delà de l’une de ces bornes, des erreurs de transport restent possibles.
+
+Le SDK Python 2.17.1 publié avec le Server natif 3.9.1 qualifié (linux/amd64, SQLite) réussit désormais les [contrôles sur le Worker réellement installé](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512) : fan-out de 300 × 10 KB dans la limite, un seul 413 typé et un seul échec structurel sans activité partielle pour une finalisation trop grande, puis une tâche réussie sur le même Worker. Cela qualifie ce couple exact Python/Server. PHP et Rust nécessitent leurs propres preuves sur installation ; le #228 partagé reste ouvert. L’acceptation des clés de requête du #216 partagé est distincte.
 
 Pour garder un achèvement sous la limite :
 
 - Découpez un fan-out important en lots plus petits répartis sur plusieurs tâches de workflow.
 - Déplacez du travail dans des workflows enfants, ou utilisez continue-as-new.
-- Stockez les arguments volumineux dans le stockage externe des payloads, afin que l’achèvement transporte des références au lieu des payloads.
+- N’utilisez le stockage externe que pour les emplacements de payloads pris en charge. Les arguments des commandes de continuation d’activité restent inline ; une autorisation de téléversement d’activité/résultat ne permet pas d’y placer des références.
 
 #### Planification des commandes Rust {#rust-completion-planning}
 
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 b53d5118f08..c2aaf777f1c 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -124,6 +124,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 
 La stack comprend le Server natif et MySQL. Compose refuse de démarrer tant que `DW_AUTH_TOKEN` n’est pas défini. Le [guide de déploiement](/docs/deployment#single-node-production) décrit le fichier d’environnement de production, les sauvegardes et les mises à niveau.
 
+Passer de native 3.8.x ou antérieur à 3.9.1 exige la [mise à niveau explicite du schéma](../deployment.md#native-schema-upgrade-3-9) avant redémarrage.
+
 ### Ports {#ports}
 
 | Service | Port | Rôle |
diff --git a/i18n/fr/source-hashes.json b/i18n/fr/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 0e1f535ef72..2a77559904b 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/deployment.md
@@ -170,6 +170,21 @@ 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.9.1 への更新 {#native-schema-upgrade-3-9}
+
+native 3.8.x 以前からの更新では、すべてのバックエンドでスキーマ更新が必要です。Server 3.9.1 は空の `dw_command_intents` テーブルを追加します。
+
+| バックエンド | 3.8.x からのスキーマ遷移 |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+すべての Server レプリカを停止し、データベースは動かしたまま、データベースと Server ストレージをバックアップしてから、3.9.1 イメージを選んで取得します。そのイメージの `schema-upgrade` を 1 回実行した後、全レプリカを同じバージョンで再起動します。Server は起動時に既存スキーマを更新せず、古いスキーマでは `native_schema_upgrade_required` で拒否します。再起動後に readiness、報告バージョン、Worker 登録を確認してください。[検証済み 3.9.1 リリースの手順](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade)に、ソースの checkout が不要な Compose コマンドがあります。
+
+MySQL と MariaDB は中断後の更新を再開でき、SQLite と PostgreSQL はトランザクションでこのステップを適用します。3.8.x へのロールバックにはバックアップの復元が必要です。3.8.0 は更新済みデータベースを `native_schema_newer_than_binary` で拒否します。3.9.0 からは追加のスキーマ更新は不要です。さらに古いバージョンでは、`schema-upgrade` が該当する [3.7 の JSON 再構築](#native-schema-upgrade-3-7)などの以前の手順も適用します。Worker protocol 1.20 と control plane 2 は変わりません。
+
 ### Server 3.8.0 へのアップグレード {#native-schema-upgrade-3-8}
 
 Server 3.8.0 では、すべてのバックエンドで native スキーマのアップグレードが必要です。native 専用のテーブル `dw_task_queue_pauses` が 1 つ追加され、空の状態で作成されます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 23e21a414e2..71d6997ac2d 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -282,6 +282,8 @@ Sticky 実行には Server イメージ専用の環境変数はありません
 
 PHP Server 2.x の設定可能な上限には、文書化された `DW_*` 設定を使ってください。コントローラーの検証上限は固定です。Native Server 3.x が対応する設定は、[実装上の注意](#native-server-3x)に記載されています。native 3.8.0 の `DW_MAX_PAYLOAD_BYTES=0` は、通常のリクエストとワークフロータスクの完了に対して 0 バイトの上限を設定し、空でないボディーを拒否します。操作名の上限は 256 バイトに固定されています。
 
+native 3.9.1 は、シグナルの `request_id` に 255 UTF-8 バイトのチェックを引き続き適用します。そのため、255 文字のマルチバイトキーでも `422 invalid_request_id` になる場合があります。[インストール済み CLI の検証](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056)でこの公開版の制限を追跡しています。共有 #216 のリクエストキー全体の合格を示すものではありません。
+
 `GET /api/cluster/info` の `limits` に現在値を公開し、クライアントが実行時に確認できます。
 
 ```json
@@ -316,23 +318,29 @@ PHP Server 2.x の設定可能な上限には、文書化された `DW_*` 設定
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-native 3.8.0 と修正後のソースにも、UTF-8 バイト数のチェックが残ります。`activity_type`、`open_signal_wait.signal_name`、明示的な `schedule_activity.queue`、`continue_as_new.workflow_type` / `queue` には、パーサーの 255 バイト上限があります（`422 invalid_request`）。子の `workflow_type` と `queue` には追加の 191 バイトチェックがあり、`422 unsupported_child_options` を返す場合があります。たとえば `é` を 128 個並べた Activity 型は 256 バイトとなり、128 文字しかなくても拒否されます。新しい文字数チェックは、これらのバイト数チェックを削除しません。
+native 3.8.0 と 3.9.1 にも、UTF-8 バイト数のチェックが残ります。`activity_type`、`open_signal_wait.signal_name`、明示的な `schedule_activity.queue`、`continue_as_new.workflow_type` / `queue` には、パーサーの 255 バイト上限があります（`422 invalid_request`）。子の `workflow_type` と `queue` には追加の 191 バイトチェックがあり、`422 unsupported_child_options` を返す場合があります。たとえば `é` を 128 個並べた Activity 型は 256 バイトとなり、128 文字しかなくても拒否されます。新しい文字数チェックは、これらのバイト数チェックを削除しません。
 
-native Server 3.8.0 は、書き込み前にこれらの名前の上限を一貫して検証しません。SQLite は長すぎる名前を警告なく保存する場合があり、ほかのバックエンドではデータベースエラーになる場合があります。[ソースの修正](https://github.com/durable-workflow/server/pull/1186)は、`commands.0.activity_type` などのフィールドごとに、書き込み前の `422` 拒否を追加しますが、検証済み Server リリースとしての公開はまだです。選択された安定版は引き続き 3.8.0 です。修正版へ更新する前に、191 文字を超える名前の既存の Activity 型とシグナル待機を確認してください。その名前を使う新しいコマンドは拒否されます。残りの識別子の調査は [Server #607](https://github.com/durable-workflow/server/issues/607) で追跡しています。上記の HTTP 操作名の 256 バイト上限は、これとは別です。
+native Server 3.9.1 には[公開済みの修正](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes)が含まれます。書き込み前に `commands.0.activity_type` など、フィールドごとの `422 validation_failed` 拒否を返します。native 3.8.0 はこれらの文字数上限を一貫して検証せず、SQLite は長すぎる名前を警告なく保存する場合があり、ほかのバックエンドではデータベースエラーになる場合がありました。更新前に、191 文字を超える名前の既存 Activity 型とシグナル待機を確認してください。その名前を使う新しいコマンドは拒否されます。残りの識別子の調査は [Server #607](https://github.com/durable-workflow/server/issues/607) で継続しています。上記の HTTP 操作名の 256 バイト上限は別の制限です。
 
 ### ワークフロータスク完了サイズ {#workflow-task-completion-size}
 
 native Server 3.6.0 以降では、コマンド付きでワークフロータスクを完了するリクエスト（`POST /api/worker/workflow-tasks/{id}/complete` と `POST /api/worker/activity-tasks/{id}/continuation/complete`）は `max_payload_bytes` の 16 倍まで許可されます。既定の 2 MiB なら 32 MiB です。この上限は `DW_MAX_PAYLOAD_BYTES` に従い、専用の設定はありません。完了の中でも、各コマンドの引数には引き続きペイロードごとの上限が適用されます。PHP Server 2.x と以前の native リリースは、他のリクエストと同じく完了を 1 ペイロード分の上限に制限します。
 
+native 3.9.1 は cluster info の `limits.max_workflow_task_completion_bytes` に実際の予算を公開します。両方の完了ルートについて、エンベロープ、メタデータ、コマンドを含む、エンコード済み JSON リクエスト本文全体のサイズです。Server のバージョンから倍率を推測したり、デコード済み引数を合計したりせず、この値を使ってください。値ごとと通常ルートの上限は変わりません。このフィールドは、外部 payload のアップロードや参照配置の追加権限を与えません。
+
+SDK のプランナーは、通常の上限より小さくても、公開された正の上限を守る必要があります。フィールドがなければ保守的なフォールバックを維持します。明示的な不正値、null、ゼロ、負数、非整数の場合はアップロード前に完了計画を拒否します。通常ルートは、この未使用の完了フィールドを無視します。
+
 それより大きい完了は、何も記録される前に `413 payload_too_large` と `limit_kind: workflow_task_completion_bytes` で拒否されます。タスクをリプレイしても同じコマンドが生成されるため、完了を再送しても同じ拒否になります。PHP SDK 3.17.0 以降は、この型付き拒否を受信した場合、完了リクエストを再送しません。Worker は `Structural limit exceeded: workflow_task_completion_bytes:` で始まり両方のサイズを示すメッセージの `fail_workflow` コマンドで実行を一度だけ失敗させ、Server はその失敗を `failure_category = structural_limit` として記録します。
 
-Python SDK 2.17 と Rust SDK 4.15 は型付き拒否の処理に対応しています。Server 3.8.0 では、大きすぎる完了リクエストが、Worker に HTTP 413 が届く前にトランスポート層で失敗することがあります。公開済み Python SDK のテストでは、`httpx.ReadError` により、ワークフローは構造上限による失敗にならず、保留中のままでした。公開済み Server での上限超過リクエストの受け入れ検証は、[Server の応答修正](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678)で引き続き対応中です。この経路の適格性が確認されるまでは、完了リクエストを小さくしてください。
+Python SDK 2.17 と Rust SDK 4.15 には型付き拒否の処理があります。Server 3.8.0 の公開済み Python 検証では HTTP 413 を受け取る前に `httpx.ReadError` が発生し、workflow が保留されました。native 3.9.1 は、残りのアップロードを最大 64 MiB、最大 2 秒間だけ破棄してから元の拒否を返し、接続を閉じることで応答経路を修正します。どちらかの境界を超えるアップロードでは、引き続きトランスポートエラーが起こり得ます。
+
+公開済み Python SDK 2.17.1 と検証済み native Server 3.9.1（linux/amd64、SQLite）は、[実際にインストールした Worker の検証](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)に合格しました。上限内の 300 × 10 KB fan-out、大きすぎる完了に対する型付き 413 が 1 回と構造的失敗が 1 回、部分的な Activity がゼロ、その後の同じ Worker でのタスク成功を確認しています。この特定の Python/Server 組み合わせの検証です。PHP と Rust にはそれぞれのインストール済み検証が必要で、共有 #228 は未完了です。共有 #216 のリクエストキー検証は別です。
 
 完了を上限内に収めるには：
 
 - 大きなファンアウトを、複数のワークフロータスクにまたがる小さなバッチに分割します。
 - 処理を子ワークフローに移すか、continue-as-new を使います。
-- 大きな引数は外部ペイロードストレージに保存し、完了にはペイロードではなく参照を含めます。
+- 外部 payload ストレージは、対応している payload 配置にだけ使ってください。Activity continuation のコマンド引数は inline のままです。Activity や結果のアップロード許可は、その引数への参照配置を許可しません。
 
 #### Rust のコマンド計画 {#rust-completion-planning}
 
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 4cc93144bc7..a7749d93216 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -114,6 +114,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 
 このスタックはネイティブ Server と MySQL で構成されます。`DW_AUTH_TOKEN` が設定されるまで Compose は起動を拒否します。本番用 env ファイル、バックアップ、アップグレードは [デプロイガイド](/docs/deployment#single-node-production)で説明しています。
 
+native 3.8.x 以前から 3.9.1 への更新では、再起動前に[明示的なスキーマ更新](../deployment.md#native-schema-upgrade-3-9)が必要です。
+
 ### ポート {#ports}
 
 | サービス | ポート | 用途 |
diff --git a/i18n/ja/source-hashes.json b/i18n/ja/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 c369ae78cf2..051bf82bddc 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/deployment.md
@@ -275,6 +275,21 @@ 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 Server 3.9.1 {#native-schema-upgrade-3-9}
+
+Atualizar do native 3.8.x ou anterior exige upgrade do esquema em todos os backends. Server 3.9.1 adiciona a tabela vazia `dw_command_intents`:
+
+| Backend | Transição de esquema desde 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Pare todas as réplicas do Server, mantenha o banco ativo, faça backup do banco e do armazenamento do Server e selecione e baixe a imagem 3.9.1. Execute o `schema-upgrade` dessa imagem uma vez antes de reiniciar todas as réplicas na mesma versão. Server não atualiza um esquema existente na inicialização: recusa o antigo com `native_schema_upgrade_required`. Verifique readiness, versão e registro do Worker após reiniciar. As [instruções qualificadas da versão 3.9.1](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade) fornecem comandos Compose sem checkout do código-fonte.
+
+MySQL e MariaDB retomam upgrades interrompidos; SQLite e PostgreSQL aplicam a etapa em transação. Voltar para 3.8.x exige restaurar o backup: 3.8.0 recusa o banco atualizado com `native_schema_newer_than_binary`. A partir de 3.9.0, nenhuma etapa extra de esquema é necessária. De versões anteriores, `schema-upgrade` também aplica as etapas passadas, incluindo a [reconstrução JSON da 3.7](#native-schema-upgrade-3-7) quando aplicável. O protocolo Worker 1.20 e o plano de controle 2 não mudam.
+
 ### Atualizar para o Server 3.8.0 {#native-schema-upgrade-3-8}
 
 O Server 3.8.0 precisa de uma atualização de esquema native em todos os backends. Ele adiciona uma tabela exclusiva do native, `dw_task_queue_pauses`, criada vazia:
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 19efac9536e..b732d952314 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -287,6 +287,8 @@ No native 3.8.0, `DW_MAX_PAYLOAD_BYTES=0` define um teto de zero bytes para
 requisições comuns e conclusões de tarefas de workflow, recusando corpos não
 vazios. O teto para nomes de operações é fixo em 256 bytes.
 
+O runtime nativo 3.9.1 ainda verifica `request_id` de sinais contra 255 bytes UTF-8. Uma chave multibyte de 255 caracteres pode retornar `422 invalid_request_id`. A [qualificação da CLI instalada](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056) registra essa limitação publicada; ela não estabelece aceitação completa de chaves sob o #216 compartilhado.
+
 Os valores configurados atualmente são publicados em `limits` na resposta de `GET /api/cluster/info`, para que clientes possam descobri-los em tempo de execução:
 
 ```json
@@ -324,8 +326,7 @@ têm limites mais restritos que os demais comandos.
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-O runtime nativo 3.8.0 e o código corrigido também mantêm verificações de bytes
-UTF-8. `activity_type`, `open_signal_wait.signal_name`, uma
+Os runtimes nativos 3.8.0 e 3.9.1 também mantêm verificações de bytes UTF-8. `activity_type`, `open_signal_wait.signal_name`, uma
 `schedule_activity.queue` explícita e `continue_as_new.workflow_type` / `queue`
 têm um limite de parser de 255 bytes (`422 invalid_request`). Os campos
 `workflow_type` e `queue` de um filho têm ainda uma verificação de 191 bytes
@@ -333,36 +334,27 @@ que pode retornar `422 unsupported_child_options`. Por exemplo, um tipo de
 atividade com 128 cópias de `é` ocupa 256 bytes e é recusado mesmo tendo apenas
 128 caracteres. As novas verificações de caracteres não removem esses limites de bytes.
 
-O Server nativo 3.8.0 não valida esses limites de nomes de forma consistente
-antes das gravações. O SQLite pode armazenar nomes longos demais silenciosamente;
-outros backends podem retornar erros de banco de dados. A [correção no código](https://github.com/durable-workflow/server/pull/1186)
-adiciona recusas `422` específicas por campo antes de gravar, como
-`commands.0.activity_type`, mas ainda aguarda uma versão publicada e qualificada
-do Server. A versão estável selecionada continua sendo 3.8.0. Antes de atualizar
-para essa versão corrigida, revise tipos de atividade e esperas de sinal cujos
-nomes excedam 191 caracteres: novos comandos com esses nomes serão recusados.
-A revisão dos demais identificadores está em [Server #607](https://github.com/durable-workflow/server/issues/607).
-O limite HTTP de 256 bytes para nomes de operações acima é independente.
+O Server nativo 3.9.1 inclui a [correção publicada](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes): recusas `422 validation_failed` por campo, como `commands.0.activity_type`, antes de gravar. O runtime nativo 3.8.0 não validava esses limites de caracteres consistentemente; o SQLite podia guardar nomes longos demais sem avisar, enquanto outros backends retornavam erros de banco. Antes de atualizar, revise tipos de atividade e esperas de sinal com nomes acima de 191 caracteres: novos comandos com esses nomes agora são recusados. A revisão dos demais identificadores continua em [Server #607](https://github.com/durable-workflow/server/issues/607). O limite HTTP de 256 bytes para nomes de operações acima é separado.
 
 ### Tamanho da conclusão de tarefa de workflow {#workflow-task-completion-size}
 
 No Server nativo 3.6.0 e posteriores, uma requisição que conclui uma tarefa de workflow com comandos (`POST /api/worker/workflow-tasks/{id}/complete` e `POST /api/worker/activity-tasks/{id}/continuation/complete`) pode ter até 16 vezes `max_payload_bytes`: 32 MiB com o padrão de 2 MiB. Ela segue `DW_MAX_PAYLOAD_BYTES` e não tem configuração própria. Os argumentos de cada comando continuam respeitando o limite por payload dentro da conclusão. O Server PHP 2.x e versões nativas anteriores limitam uma conclusão a um limite de payload, como qualquer outra requisição.
 
+O runtime nativo 3.9.1 publica o orçamento real em `limits.max_workflow_task_completion_bytes` no cluster info. Ele mede o corpo JSON codificado completo, incluindo envelopes, metadados e comandos, nas duas rotas de conclusão. Use esse valor em vez de inferir um multiplicador pela versão ou somar argumentos decodificados. Os limites por valor e de rotas comuns não mudam. O campo não concede autorização adicional para upload de payloads externos ou posicionamento de referências.
+
+Os planejadores dos SDKs devem respeitar um limite positivo publicado mesmo abaixo do limite comum. Campo ausente mantém o fallback conservador; um valor explícito malformado, nulo, zero, negativo ou não inteiro recusa o planejamento antes do upload. Rotas comuns ignoram esse campo de conclusão não utilizado.
+
 Uma conclusão maior é recusada com `413 payload_too_large` e `limit_kind: workflow_task_completion_bytes` antes que algo seja registrado. Reexecutar a tarefa produz os mesmos comandos, então reenviar a conclusão recebe a mesma recusa. Quando o PHP SDK 3.17.0 ou posterior recebe essa recusa tipada, não reenvia a conclusão: o worker falha a execução uma única vez com um comando `fail_workflow` cuja mensagem começa com `Structural limit exceeded: workflow_task_completion_bytes:` e informa os dois tamanhos, e o Server registra a falha com `failure_category = structural_limit`.
 
-O Python SDK 2.17 e o Rust SDK 4.15 tratam a recusa tipada. No Server 3.8.0,
-uma conclusão grande demais pode falhar no transporte antes que o worker
-receba HTTP 413. No teste com o SDK de Python publicado, `httpx.ReadError`
-deixou o workflow pendente em vez de falhar por um limite estrutural. A
-aceitação de requisições acima do limite no Server publicado continua aberta
-na [correção da resposta do Server](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678).
-Reduza as conclusões até que esse caminho seja qualificado.
+Python SDK 2.17 e Rust SDK 4.15 incluem tratamento para a recusa tipada. No Server 3.8.0, um controle Python publicado recebeu `httpx.ReadError` antes do HTTP 413 e deixou o workflow pendente. O runtime nativo 3.9.1 corrige a resposta descartando dados de forma limitada: no máximo 64 MiB da carga restante por até dois segundos, antes de devolver a recusa original e fechar a conexão. Uploads que ultrapassem qualquer limite ainda podem ter erros de transporte.
+
+O Python SDK 2.17.1 publicado com o Server nativo 3.9.1 qualificado (linux/amd64, SQLite) agora passa nos [controles com Worker realmente instalado](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro do limite, um único 413 tipado e uma única falha estrutural sem atividades parciais para uma conclusão grande demais, e depois uma tarefa bem-sucedida no mesmo Worker. Isso qualifica esse par exato Python/Server. PHP e Rust exigem sua própria aceitação instalada; o #228 compartilhado continua aberto. A aceitação de chaves de requisição do #216 compartilhado é separada.
 
 Para manter uma conclusão dentro do limite:
 
 - Divida um fan-out grande em lotes menores distribuídos entre tarefas de workflow.
 - Mova trabalho para workflows filhos, ou use continue-as-new.
-- Guarde argumentos grandes no armazenamento externo de payloads, para que a conclusão leve referências em vez dos payloads.
+- Use armazenamento externo apenas para posições de payload suportadas. Argumentos de comandos de continuação de atividades permanecem inline; permissão de upload para atividade/resultado não autoriza referências nesses argumentos.
 
 #### Planejamento de comandos em Rust {#rust-completion-planning}
 
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 466e984e73c..75c810cf0e0 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
@@ -124,6 +124,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 
 O conjunto é formado pelo Server nativo e pelo MySQL. O Compose se recusa a iniciar até que `DW_AUTH_TOKEN` seja definido. O [guia de implantação](/docs/deployment#single-node-production) trata do arquivo de ambiente de produção, de backups e de atualizações.
 
+Atualizar do native 3.8.x ou anterior para 3.9.1 exige o [upgrade explícito do esquema](../deployment.md#native-schema-upgrade-3-9) antes de reiniciar.
+
 ### Portas {#ports}
 
 | Serviço | Porta | Finalidade |
diff --git a/i18n/pt-BR/source-hashes.json b/i18n/pt-BR/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 78f6c607927..3508f381ab7 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/deployment.md
@@ -269,6 +269,21 @@ 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.9.1 {#native-schema-upgrade-3-9}
+
+Оновлення з native 3.8.x або ранішої версії потребує оновлення схеми на кожному бекенді. Server 3.9.1 додає порожню таблицю `dw_command_intents`:
+
+| Бекенд | Перехід схеми з 3.8.x |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+Зупиніть усі репліки Server, залиште базу даних працювати, створіть резервні копії бази та сховища Server, а тоді виберіть і завантажте образ 3.9.1. Запустіть його `schema-upgrade` один раз перед перезапуском усіх реплік на тій самій версії. Server не оновлює наявну схему при запуску: він відмовляє зі старою схемою через `native_schema_upgrade_required`. Після перезапуску перевірте readiness, версію та реєстрацію Worker. [Кваліфіковані інструкції релізу 3.9.1](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade) містять команди Compose без checkout вихідного коду.
+
+MySQL і MariaDB продовжують перерване оновлення; SQLite та PostgreSQL застосовують крок транзакційно. Відкат до 3.8.x потребує відновлення резервної копії: 3.8.0 відмовляє з оновленою базою через `native_schema_newer_than_binary`. Із 3.9.0 додатковий крок схеми не потрібен. Для старіших версій `schema-upgrade` застосовує також попередні кроки, зокрема [перебудову JSON у 3.7](#native-schema-upgrade-3-7), якщо вона потрібна. Протокол Worker 1.20 і control plane 2 не змінюються.
+
 ### Оновлення до Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 потребує нативного оновлення схеми на кожному бекенді. Він додає одну таблицю лише для native, `dw_task_queue_pauses`, яка створюється порожньою:
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 212ce1a85c0..a9db5302cf5 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -382,6 +382,8 @@ PHP Server 2.x. Межі перевірок контролера фіксова
 завершень workflow task, тому непорожні тіла відхиляються. Межа назв операцій
 фіксована й становить 256 байтів.
 
+Нативний runtime 3.9.1 досі перевіряє `request_id` сигналів на межу 255 байтів UTF-8. Багатобайтовий ключ із 255 символів може повернути `422 invalid_request_id`. [Кваліфікація встановленої CLI](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056) відстежує це опубліковане обмеження; вона не доводить повної відповідності ключів спільному #216.
+
 Поточні значення публікуються під `limits` у відповіді `GET /api/cluster/info`,
 тому клієнти можуть дізнатися їх під час виконання:
 
@@ -423,7 +425,7 @@ runtime також діють. Рядок ID workflow стосується ок
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-Нативний runtime 3.8.0 і виправлений код також зберігають перевірки байтів UTF-8.
+Нативні runtime 3.8.0 та 3.9.1 також зберігають перевірки байтів UTF-8.
 `activity_type`, `open_signal_wait.signal_name`, явно задана
 `schedule_activity.queue` та `continue_as_new.workflow_type` / `queue`
 мають межу парсера у 255 байтів (`422 invalid_request`). Поля `workflow_type`
@@ -432,36 +434,27 @@ runtime також діють. Рядок ID workflow стосується ок
 128 повторень `é` займає 256 байтів і відхиляється, хоча має лише 128 символів.
 Нові перевірки символів не скасовують цих перевірок байтів.
 
-Нативний Server 3.8.0 не завжди перевіряє ці межі імен перед записом. SQLite може
-непомітно зберігати задовгі імена; інші бекенди можуть повертати помилки бази
-даних. [Виправлення в коді](https://github.com/durable-workflow/server/pull/1186)
-додає відмови `422` для конкретних полів перед записом, наприклад
-`commands.0.activity_type`, але ще очікує на кваліфікований опублікований реліз
-Server. Обрана стабільна версія залишається 3.8.0. Перед оновленням до виправленого
-релізу перевірте наявні типи активностей та очікування сигналів з іменами довшими
-за 191 символ: нові команди з такими іменами будуть відхилені. Перевірка решти
-ідентифікаторів відстежується в [Server #607](https://github.com/durable-workflow/server/issues/607).
-Зазначена вище HTTP-межа імен операцій у 256 байтів є окремим обмеженням.
+Нативний Server 3.9.1 містить [опубліковане виправлення](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes): відмови `422 validation_failed` для конкретних полів, наприклад `commands.0.activity_type`, перед записом. Нативний runtime 3.8.0 не завжди перевіряв ці межі символів; SQLite міг непомітно зберігати задовгі імена, тоді як інші бекенди повертали помилки бази даних. Перед оновленням перевірте типи активностей та очікування сигналів з іменами понад 191 символ: нові команди з такими іменами тепер відхиляються. Перевірка решти ідентифікаторів триває в [Server #607](https://github.com/durable-workflow/server/issues/607). Зазначена вище HTTP-межа імен операцій у 256 байтів є окремою.
 
 ### Розмір завершення завдання workflow {#workflow-task-completion-size}
 
 У нативному Server 3.6.0 і новіших запит, що завершує завдання workflow з командами (`POST /api/worker/workflow-tasks/{id}/complete` і `POST /api/worker/activity-tasks/{id}/continuation/complete`), може мати розмір до 16 × `max_payload_bytes`: 32 MiB за типового значення 2 MiB. Ліміт іде за `DW_MAX_PAYLOAD_BYTES` і не має власного параметра. Аргументи кожної команди всередині завершення й далі мають вкладатися в ліміт на один payload. PHP Server 2.x і попередні нативні випуски обмежують завершення одним лімітом payload, як і будь-який інший запит.
 
+Нативний runtime 3.9.1 публікує фактичний бюджет як `limits.max_workflow_task_completion_bytes` у cluster info. Для обох маршрутів завершення він вимірює все закодоване JSON-тіло запиту разом з оболонками, метаданими й командами. Використовуйте це значення, а не множник, виведений з версії, чи суму декодованих аргументів. Межі окремих значень та звичайних маршрутів не змінюються. Поле не надає додаткових прав на завантаження зовнішніх payload або розміщення посилань.
+
+Планувальники SDK мають дотримуватися позитивної опублікованої межі, навіть якщо вона нижча за звичайну. Відсутнє поле зберігає консервативний запасний варіант; явно некоректне, null, нульове, від’ємне або неціле значення відхиляє планування до завантаження. Звичайні маршрути ігнорують це невикористане поле завершення.
+
 Більше завершення відхиляється з `413 payload_too_large` і `limit_kind: workflow_task_completion_bytes` ще до того, як щось буде записано. Повторне відтворення завдання дає ті самі команди, тож повторне надсилання завершення отримає ту саму відмову. Коли PHP SDK 3.17.0 або новіший отримує цю типізовану відмову, він не надсилає запит завершення повторно: worker один раз завершує запуск помилкою через команду `fail_workflow`, повідомлення якої починається з `Structural limit exceeded: workflow_task_completion_bytes:` і називає обидва розміри, а Server записує помилку з `failure_category = structural_limit`.
 
-Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану відмову. На Server
-3.8.0 завеликий запит завершення може дати збій транспорту до отримання worker
-відповіді HTTP 413. У тесті з опублікованим Python SDK помилка
-`httpx.ReadError` залишила workflow в очікуванні замість структурної помилки.
-Перевірка завеликих запитів на опублікованому Server ще не завершена в межах
-[виправлення відповіді Server](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678).
-Зменшуйте запити завершення, доки цей шлях не пройде кваліфікацію.
+Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану відмову. На Server 3.8.0 опублікований контроль Python отримав `httpx.ReadError` до HTTP 413 і залишив workflow в очікуванні. Нативний runtime 3.9.1 виправляє відповідь обмеженим відкиданням решти запиту: щонайбільше 64 MiB за щонайбільше дві секунди перед початковою відмовою та закриттям з’єднання. Завантаження поза будь-якою з цих меж і далі можуть мати транспортні помилки.
+
+Опублікований Python SDK 2.17.1 із кваліфікованим нативним Server 3.9.1 (linux/amd64, SQLite) тепер проходить [контролі реально встановленого Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out 300 × 10 KB у межах бюджету, одна типізована 413 і один структурний збій без часткових активностей для завеликого завершення, а потім успішне завдання на тому самому Worker. Це кваліфікує саме цю пару Python/Server. PHP і Rust потребують власних перевірок установлених пакетів; спільне #228 залишається відкритим. Перевірка ключів запитів у спільному #216 є окремою.
 
 Щоб завершення вкладалося в ліміт:
 
 - Розділіть великий fan-out на менші пакети в кількох завданнях workflow.
 - Перенесіть роботу в дочірні workflow або використайте continue-as-new.
-- Зберігайте великі аргументи в зовнішньому сховищі payload, щоб завершення містило посилання замість самих payload.
+- Використовуйте зовнішнє сховище лише для підтримуваних позицій payload. Аргументи команд продовження активності залишаються inline; дозвіл завантаження для активності чи результату не дозволяє посилань у цих аргументах.
 
 #### Планування команд Rust {#rust-completion-planning}
 
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 60121eeb16a..5fca8f0ac55 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server.md
@@ -171,6 +171,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 задано `DW_AUTH_TOKEN`. [Посібник розгортання](/docs/deployment#single-node-production)
 описує production-файл env, резервні копії та оновлення.
 
+Оновлення з native 3.8.x або ранішої версії до 3.9.1 потребує [явного оновлення схеми](../deployment.md#native-schema-upgrade-3-9) перед перезапуском.
+
 ### Порти {#ports}
 
 | Сервіс | Порт | Призначення |
diff --git a/i18n/uk/source-hashes.json b/i18n/uk/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "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 67b20251881..d76c7399628 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/deployment.md
@@ -169,6 +169,21 @@ 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.9.1 {#native-schema-upgrade-3-9}
+
+从 native 3.8.x 或更早版本升级时，所有后端都必须升级 schema。Server 3.9.1 添加空的 `dw_command_intents` 表：
+
+| 后端 | 从 3.8.x 开始的 schema 迁移 |
+|---|---|
+| SQLite | 12 → 13 |
+| PostgreSQL | 13 → 14 |
+| MariaDB | 13 → 14 |
+| MySQL | 14 → 15 |
+
+停止所有 Server 副本，保持数据库运行，备份数据库和 Server 存储，然后选择并拉取 3.9.1 镜像。在以相同版本重启所有副本前，用该镜像运行一次 `schema-upgrade`。Server 不会在启动时升级已有 schema：旧 schema 会被 `native_schema_upgrade_required` 拒绝。重启后检查 readiness、报告的版本和 Worker 注册。[经过验证的 3.9.1 发布说明](https://github.com/durable-workflow/server/releases/tag/3.9.1#upgrade)提供无需 checkout 源码的 Compose 命令。
+
+MySQL 和 MariaDB 可继续被中断的升级；SQLite 和 PostgreSQL 在事务中应用此步骤。回退到 3.8.x 必须恢复备份：3.8.0 会以 `native_schema_newer_than_binary` 拒绝升级后的数据库。从 3.9.0 升级不需要额外的 schema 步骤。更早版本的 `schema-upgrade` 还会应用之前的步骤，包括适用的 [3.7 JSON 重建](#native-schema-upgrade-3-7)。Worker protocol 1.20 和 control plane 2 保持不变。
+
 ### 升级到 Server 3.8.0 {#native-schema-upgrade-3-8}
 
 Server 3.8.0 在每种后端上都需要 native 架构升级。它新增一张仅 native 使用的表 `dw_task_queue_pauses`，创建时为空：
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 2870fd3617a..949b356b6bb 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -282,6 +282,8 @@ Sticky 执行没有独立的 Server 镜像环境变量。关于 sticky 缓存生
 
 PHP Server 2.x 的可配置限制请使用已记录的 `DW_*` 设置。控制器校验上限是固定的。Native Server 3.x 支持的设置见其[实现说明](#native-server-3x)。在 native 3.8.0 中，`DW_MAX_PAYLOAD_BYTES=0` 会将普通请求和工作流任务完成请求的上限设为零字节，拒绝非空请求体。操作名上限固定为 256 字节。
 
+原生 3.9.1 仍对信号的 `request_id` 执行 255 个 UTF-8 字节的检查。因此，255 个字符的多字节键也可能返回 `422 invalid_request_id`。[安装后 CLI 验证](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056)跟踪这一已发布版本的限制；该验证不代表共享 #216 的请求键完整验收通过。
+
 当前配置值发布在 `GET /api/cluster/info` 响应的 `limits` 下，客户端可在运行时发现这些限制：
 
 ```json
@@ -316,23 +318,29 @@ PHP Server 2.x 的可配置限制请使用已记录的 `DW_*` 设置。控制器
 | `workflow_type` | 255 | `continue_as_new` |
 | `workflow_type` / `queue` | 191 | `start_child_workflow` |
 
-原生 3.8.0 和修复后的源码都仍有 UTF-8 字节检查。`activity_type`、`open_signal_wait.signal_name`、显式指定的 `schedule_activity.queue` 以及 `continue_as_new.workflow_type` / `queue` 使用解析器的 255 字节上限（`422 invalid_request`）。子调用的 `workflow_type` 和 `queue` 还受到 191 字节检查，可能返回 `422 unsupported_child_options`。例如，由 128 个 `é` 组成的 activity 类型占 256 字节，即使只有 128 个字符也会被拒绝。新的字符数检查不会取消这些字节检查。
+原生 3.8.0 和 3.9.1 都仍有 UTF-8 字节检查。`activity_type`、`open_signal_wait.signal_name`、显式指定的 `schedule_activity.queue` 以及 `continue_as_new.workflow_type` / `queue` 使用解析器的 255 字节上限（`422 invalid_request`）。子调用的 `workflow_type` 和 `queue` 还受到 191 字节检查，可能返回 `422 unsupported_child_options`。例如，由 128 个 `é` 组成的 activity 类型占 256 字节，即使只有 128 个字符也会被拒绝。新的字符数检查不会取消这些字节检查。
 
-原生 Server 3.8.0 不会在写入前一致地校验这些命令名称上限。SQLite 可能静默保存过长的名称，其他后端可能返回数据库错误。[源码修复](https://github.com/durable-workflow/server/pull/1186)会在写入前返回针对具体字段的 `422` 拒绝，例如 `commands.0.activity_type`，但仍在等待经过验证的 Server 发布版本。当前选择的稳定版仍为 3.8.0。升级到修复版本前，请检查名称超过 191 个字符的已有 activity 类型和信号等待：使用这些名称的新命令将被拒绝。其余标识符的检查由 [Server #607](https://github.com/durable-workflow/server/issues/607) 跟踪。上述 HTTP 操作名的 256 字节上限是独立的限制。
+原生 Server 3.9.1 包含[已发布的修复](https://github.com/durable-workflow/server/releases/tag/3.9.1#other-changes)：在写入前返回针对具体字段的 `422 validation_failed` 拒绝，例如 `commands.0.activity_type`。原生 3.8.0 不会一致地校验这些字符上限；SQLite 可能静默保存过长的名称，其他后端则可能返回数据库错误。升级前请检查名称超过 191 个字符的已有 activity 类型和信号等待：使用这些名称的新命令现在会被拒绝。其余标识符的检查仍由 [Server #607](https://github.com/durable-workflow/server/issues/607) 跟踪。上述 HTTP 操作名的 256 字节上限是独立限制。
 
 ### 工作流任务完成大小 {#workflow-task-completion-size}
 
 在原生 Server 3.6.0 及以上，带命令完成工作流任务的请求（`POST /api/worker/workflow-tasks/{id}/complete` 和 `POST /api/worker/activity-tasks/{id}/continuation/complete`）最多可达 `max_payload_bytes` 的 16 倍：默认 2 MiB 时为 32 MiB。该上限跟随 `DW_MAX_PAYLOAD_BYTES`，没有单独的设置。完成请求中每个命令的参数仍须符合单个载荷上限。PHP Server 2.x 和更早的原生版本与其他请求一样，将完成请求限制为一个载荷上限。
 
+原生 3.9.1 在 cluster info 中通过 `limits.max_workflow_task_completion_bytes` 公布实际预算。它对两个完成路由都计量整个编码后 JSON 请求体，包括 envelope、元数据和命令。应使用该值，而不是按 Server 版本推断倍数或累加解码后的参数大小。单个值和普通路由的上限不变。此字段不会授予额外的外部 payload 上传权限或引用放置权限。
+
+SDK 规划器必须遵守公布的正整数上限，即使它低于普通上限。字段缺失时保留保守的回退行为；显式格式错误、null、零、负数或非整数值会在上传前拒绝完成规划。普通路由忽略此未使用的完成字段。
+
 更大的完成请求会在记录任何内容之前以 `413 payload_too_large` 和 `limit_kind: workflow_task_completion_bytes` 被拒绝。重放该任务会生成相同的命令，因此重新发送完成请求会得到同样的拒绝。PHP SDK 3.17.0 及以上在收到这种类型化拒绝后不会重新发送完成请求：Worker 用一条 `fail_workflow` 命令让运行失败一次，其消息以 `Structural limit exceeded: workflow_task_completion_bytes:` 开头并给出两个大小，Server 以 `failure_category = structural_limit` 记录该失败。
 
-Python SDK 2.17 和 Rust SDK 4.15 包含对类型化拒绝的处理。在 Server 3.8.0 上，过大的完成请求可能在 Worker 收到 HTTP 413 之前就在传输层失败。在已发布 Python SDK 的测试中，`httpx.ReadError` 使工作流保持待处理状态，而没有因结构限制失败。已发布 Server 的超限请求验收仍由 [Server 响应修复](https://github.com/durable-workflow/.github/issues/228#issuecomment-6848969678)跟进。在该路径通过资格验证之前，请减小完成请求。
+Python SDK 2.17 和 Rust SDK 4.15 包含类型化拒绝处理。Server 3.8.0 的已发布 Python 验证在收到 HTTP 413 前遇到 `httpx.ReadError`，使 workflow 保持待定。原生 3.9.1 通过有界丢弃请求余下数据修复此响应路径：最多 64 MiB、最多两秒，然后返回原始拒绝并关闭连接。超出任一边界的上传仍可能遇到传输错误。
+
+已发布的 Python SDK 2.17.1 与经过验证的原生 Server 3.9.1（linux/amd64、SQLite）现已通过[实际安装 Worker 的验证](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)：预算内 300 × 10 KB fan-out；过大的完成请求只产生一次类型化 413 和一次结构性失败，部分 activity 为零；随后同一 Worker 成功执行后续任务。此结果只验证这个确切的 Python/Server 组合。PHP 和 Rust 仍需各自的安装后验证；共享 #228 仍未关闭。共享 #216 的请求键验证是独立的。
 
 要让完成请求保持在上限之内：
 
 - 将大型扇出拆分为分布在多个工作流任务中的较小批次。
 - 将工作移到子工作流中，或使用 continue-as-new。
-- 将大型参数存入外部载荷存储，使完成请求携带引用而不是载荷本身。
+- 外部 payload 存储仅用于受支持的 payload 位置。activity continuation 命令参数仍须 inline；activity/result 上传许可不授权在这些命令参数中放置引用。
 
 #### Rust 命令规划 {#rust-completion-planning}
 
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 42d2b10ec55..ad8fb350630 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
@@ -113,6 +113,8 @@ curl -H "Authorization: Bearer $DW_AUTH_TOKEN" \
 
 该栈包含原生 Server 和 MySQL。未设置 `DW_AUTH_TOKEN` 时，Compose 会拒绝启动。生产 env 文件、备份和升级见[部署指南](/docs/deployment#single-node-production)。
 
+从 native 3.8.x 或更早版本升级到 3.9.1 时，必须在重启前[显式升级 schema](../deployment.md#native-schema-upgrade-3-9)。
+
 ### 端口 {#ports}
 
 | 服务 | 端口 | 用途 |
diff --git a/i18n/zh-Hans/source-hashes.json b/i18n/zh-Hans/source-hashes.json
index 1d7861a4083..7b298af1d22 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": "b5f1618dd242875bcab7bffc54bbd0dbacdeacd4e8da50044fbea3287ae1f616",
+  "deployment.md": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -89,9 +89,9 @@
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "a14a4772b762e0423c8cf27e0ae9d2b5f79c06d8dd4e193bf86bb3a911e09e27",
+  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "2c03845c0979f62bc7ab3208cf09820844b224e548f10fb7d1656852e3428445",
+  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",

From ad73072319b45096e7b9c04d5d26fda00412b3b5 Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:37:54 +0000
Subject: [PATCH 5/6] Select qualified Server Chart and Rust releases with
 scoped feature evidence

---
 docs/polyglot/rust.md                         | 20 +++++++++++++++----
 docs/polyglot/server-config-reference.md      | 20 ++++++++++---------
 .../current/polyglot/rust.md                  |  8 ++++----
 .../polyglot/server-config-reference.md       | 11 ++--------
 i18n/de/source-hashes.json                    |  4 ++--
 .../current/polyglot/rust.md                  |  8 ++++----
 .../polyglot/server-config-reference.md       | 11 ++--------
 i18n/es/source-hashes.json                    |  4 ++--
 .../current/polyglot/rust.md                  |  8 ++++----
 .../polyglot/server-config-reference.md       | 11 ++--------
 i18n/fr/source-hashes.json                    |  4 ++--
 .../current/polyglot/rust.md                  |  6 ++++--
 .../polyglot/server-config-reference.md       |  4 ++--
 i18n/ja/source-hashes.json                    |  4 ++--
 .../current/polyglot/rust.md                  |  8 ++++----
 .../polyglot/server-config-reference.md       | 11 ++--------
 i18n/pt-BR/source-hashes.json                 |  4 ++--
 .../current/polyglot/rust.md                  |  8 ++++----
 .../polyglot/server-config-reference.md       | 10 ++--------
 i18n/uk/source-hashes.json                    |  4 ++--
 .../current/polyglot/rust.md                  |  6 ++++--
 .../polyglot/server-config-reference.md       |  4 ++--
 i18n/zh-Hans/source-hashes.json               |  4 ++--
 static/stable-releases.json                   | 16 +++++++--------
 24 files changed, 91 insertions(+), 107 deletions(-)

diff --git a/docs/polyglot/rust.md b/docs/polyglot/rust.md
index 5a43d2fee12..a546ce8287d 100644
--- a/docs/polyglot/rust.md
+++ b/docs/polyglot/rust.md
@@ -148,9 +148,11 @@ is `Ok(Value::Null)`. Receipt reads preserve the explicit `update_status`.
 See the [Client API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 for the Rust interface.
 
-Rust SDK 4.15.0 still applies the ordinary payload ceiling to the whole
-command batch. See the [known planner limit](./server-config-reference.md#rust-completion-planning)
-before running a large fan-out without external payload storage.
+Rust SDK 4.16 uses the Server's explicit
+`limits.max_workflow_task_completion_bytes` budget for completion planning.
+Older producers without that field keep the conservative ordinary cap. See
+[completion planning](./server-config-reference.md#rust-completion-planning)
+for the qualified native 3.9.1 tuple and payload-placement limits.
 
 ## Condition wait deadlines and worker upgrades {#condition-wait-deadlines}
 
@@ -235,12 +237,22 @@ Each observed client request, worker poll or claimed-task dispatch increments on
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-Client tag keys are exactly `method`, `route`, `plane`, `status_code`, `outcome`; worker keys are `task_kind`, `task_queue`, `outcome`. Reviewed route placeholders omit IDs, query strings, payloads and credentials; unknown paths use `unknown`. Queue names are application-controlled: use a bounded set, not one queue per run.
+For the counter/duration pairs above, client tag keys are exactly `method`, `route`, `plane`, `status_code`, `outcome`; worker keys are `task_kind`, `task_queue`, `outcome`. Reviewed route placeholders omit IDs, query strings, payloads and credentials; unknown paths use `unknown`. Queue names are application-controlled: use a bounded set, not one queue per run.
 
 Client outcomes include `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` and `pending` for a cancelled future. `status_code` keeps an observed decimal HTTP status, otherwise `none`. Rust exception outcome names need not match another SDK’s names.
 
 One client observation includes internal transport/storage-admission retries and response/payload handling; application/worker-managed calls are separate observations. A lazy iterator observes each fetched page. Worker polls include managed retry/backoff and distinguish `task`, `empty`, `backpressure`, `error`. Task outcomes `completed`, `failed`, `expired` describe dispatch processing, not the workflow’s terminal state. These are process observations, not durable counts, billing units or schedule-to-start latency; abrupt process loss can omit a final sample.
 
+Rust SDK 4.16 adds the seventh instrument,
+`durable_workflow_worker_task_schedule_to_start_seconds`, with only
+`task_kind` and `task_queue` tags. It records Server-measured eligibility-to-claim
+delay in seconds when the producer advertises `claimed_task_ready_age` and
+supplies valid `ready_age_ms`. Missing, invalid or unsupported data produces no
+sample; the SDK never invents a zero. The
+[published 4.16/native 3.9.1 controls](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)
+(linux/amd64, SQLite) qualify all seven metrics, workflow/activity ready-age
+observations and the Prometheus adapter.
+
 For the official Prometheus adapter, enable the optional `metrics-prometheus` Cargo feature. This example uses the exact released dependency recipe:
 
 ```toml
diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index d8556ba8229..3024320bc04 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -472,8 +472,8 @@ Published Python SDK 2.17.1 with qualified native Server 3.9.1
 [actual installed-worker controls](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512):
 300 × 10 KB within-cap fan-out, one typed 413 and one structural failure with
 zero partial activities for an oversized completion, then a successful task on
-the same worker. This qualifies that exact Python/Server tuple. PHP and Rust
-require their own installed acceptance; shared #228 remains open. Request-key
+the same worker. This qualifies that exact Python/Server tuple. PHP requires its own installed
+acceptance; Rust 4.16 is qualified below. Shared #228 remains open. Request-key
 acceptance under shared #216 is separate.
 
 To keep a completion within the limit:
@@ -486,13 +486,15 @@ To keep a completion within the limit:
 
 #### Rust command planning {#rust-completion-planning}
 
-Rust SDK 4.15.0 still uses the ordinary per-payload limit as the aggregate
-command-planning ceiling (2 MiB by default), before the Server's larger
-completion allowance. Without namespace external payload storage, the
-published 300 × 10 KB fan-out is refused with `external_payload_unavailable`;
-the worker exits and the run remains pending. Use smaller command batches
-while the [SDK aggregate planner fix](https://github.com/durable-workflow/sdk-rust/issues/254)
-is pending. This SDK path does not yet implement the larger Server allowance.
+Rust SDK 4.16 uses the positive explicit completion budget advertised by the
+producer. The [published 4.16/native 3.9.1 controls](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)
+(linux/amd64, SQLite) pass 300 × 10 KB inline fan-out without external storage,
+an oversized 60 × 450 KB batch failing structurally with zero partial activities,
+and a successful follow-up on the same worker. Without the explicit field,
+older producers keep the conservative ordinary cap. The larger budget grants
+no new upload or reference-placement authority; activity-continuation command
+arguments remain inline. These controls do not qualify request-key retries
+under shared #216 or native timeout cleanup.
 
 ## Docker Bootstrap And Provenance
 
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 60d79901306..0d99e15bb39 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -142,9 +142,7 @@ Ein abgeschlossenes null-Ergebnis ist `Ok(Value::Null)`. Ergebnisbestätigungen
 erhalten den expliziten `update_status`. Die Rust-Schnittstelle steht in der
 [Client-API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome).
 
-Rust SDK 4.15.0 wendet die gewöhnliche Payload-Grenze weiterhin auf den ganzen
-Befehlsbatch an. Beachten Sie die [bekannte Planergrenze](./server-config-reference.md#rust-completion-planning),
-bevor Sie einen großen Fan-out ohne externen Payload-Speicher ausführen.
+Rust SDK 4.16 verwendet für die Completion-Planung das explizite Server-Budget `limits.max_workflow_task_completion_bytes`. Ältere Producer ohne dieses Feld behalten die konservative gewöhnliche Grenze. Siehe [Completion-Planung](./server-config-reference.md#rust-completion-planning) für das qualifizierte native3.9.1-Paar und die Grenzen der Payload-Platzierung.
 
 ## Fristen für Bedingungswarteoperationen und Worker-Upgrades {#condition-wait-deadlines}
 
@@ -233,12 +231,14 @@ Jede beobachtete Clientanfrage, Worker-Abfrage oder Verarbeitung eines bezogenen
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-Die Client-Tag-Schlüssel sind genau `method`, `route`, `plane`, `status_code`, `outcome`; beim Worker `task_kind`, `task_queue`, `outcome`. Geprüfte Routenplatzhalter enthalten keine IDs, Abfragezeichenfolgen, Payloads oder Zugangsdaten; unbekannte Pfade nutzen `unknown`. Queuenamen kontrolliert die Anwendung: begrenzte Mengen statt einer Queue pro Lauf.
+Für die obigen Zähler-/Dauerpaare gilt: Die Client-Tag-Schlüssel sind genau `method`, `route`, `plane`, `status_code`, `outcome`; beim Worker `task_kind`, `task_queue`, `outcome`. Geprüfte Routenplatzhalter enthalten keine IDs, Abfragezeichenfolgen, Payloads oder Zugangsdaten; unbekannte Pfade nutzen `unknown`. Queuenamen kontrolliert die Anwendung: begrenzte Mengen statt einer Queue pro Lauf.
 
 Client-Ergebnisse umfassen `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` und `pending` für ein abgebrochenes Future. `status_code` erhält einen beobachteten dezimalen HTTP-Status, sonst `none`. Rust-Ausnahmenamen müssen nicht mit anderen SDKs übereinstimmen.
 
 Eine Clientbeobachtung umfasst interne Transport-/Storage-Admission-Wiederholungen und Antwort-/Payload-Verarbeitung; getrennte Anwendungs-/Worker-Aufrufe bleiben getrennt. Ein verzögerter Iterator beobachtet jede angefragte Seite. Worker-Polls enthalten verwaltete Wiederholungen/Backoff und unterscheiden `task`, `empty`, `backpressure`, `error`. Task-Ergebnisse `completed`, `failed`, `expired` beschreiben die Verarbeitung, nicht den Workflow-Endzustand. Dies sind Prozessbeobachtungen, keine dauerhaften Zählungen, Abrechnungseinheiten oder Schedule-to-start-Latenzen; abrupter Prozessverlust kann die letzte Probe auslassen.
 
+Rust SDK 4.16 ergänzt das siebte Instrument `durable_workflow_worker_task_schedule_to_start_seconds` mit ausschließlich `task_kind`- und `task_queue`-Tags. Es erfasst die vom Server gemessene Zeit zwischen Ausführungsberechtigung und Claim in Sekunden, wenn der Producer `claimed_task_ready_age` veröffentlicht und gültige `ready_age_ms` liefert. Fehlende, ungültige oder nicht unterstützte Daten erzeugen keinen Messwert; das SDK erfindet keine Null. Die [Kontrollen mit veröffentlichtem4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifizieren alle sieben Metriken, Workflow-/Activity-Ready-Age und den Prometheus-Adapter.
+
 Für den offiziellen Prometheus-Adapter aktivieren Sie das optionale Cargo-Feature `metrics-prometheus`. Das Beispiel nutzt die veröffentlichten Abhängigkeiten:
 
 ```toml
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 9e0b3756ee0..c819b450d0d 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -359,7 +359,7 @@ Ein größerer Abschluss wird mit `413 payload_too_large` und `limit_kind: workf
 
 Python SDK 2.17 und Rust SDK 4.15 behandeln die typisierte Ablehnung. Auf Server 3.8.0 traf ein veröffentlichter Python-Kontrolllauf vor HTTP 413 auf `httpx.ReadError` und ließ den Workflow offen. Native 3.9.1 korrigiert diesen Antwortpfad durch begrenztes Verwerfen der Anfrage: höchstens 64 MiB verbleibende Upload-Daten und höchstens zwei Sekunden, bevor die ursprüngliche Ablehnung zurückgegeben und die Verbindung geschlossen wird. Außerhalb dieser Grenzen können weiterhin Transportfehler auftreten.
 
-Das veröffentlichte Python SDK 2.17.1 mit qualifiziertem nativem Server 3.9.1 (linux/amd64, SQLite) besteht nun die [Kontrollen mit tatsächlich installiertem Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): Fan-out von 300 × 10 KB innerhalb der Grenze, genau ein typisiertes 413 und ein struktureller Fehler ohne teilweise gestartete Aktivitäten bei übergroßer Completion, danach eine erfolgreiche Aufgabe auf demselben Worker. Dies qualifiziert genau dieses Python/Server-Paar. PHP und Rust benötigen eigene installierte Akzeptanznachweise; das gemeinsame #228 bleibt offen. Die Request-Key-Akzeptanz unter dem gemeinsamen #216 ist separat.
+Das veröffentlichte Python SDK 2.17.1 mit qualifiziertem nativem Server 3.9.1 (linux/amd64, SQLite) besteht nun die [Kontrollen mit tatsächlich installiertem Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): Fan-out von 300 × 10 KB innerhalb der Grenze, genau ein typisiertes 413 und ein struktureller Fehler ohne teilweise gestartete Aktivitäten bei übergroßer Completion, danach eine erfolgreiche Aufgabe auf demselben Worker. Dies qualifiziert genau dieses Python/Server-Paar. PHP benötigt einen eigenen installierten Akzeptanznachweis; Rust4.16 ist unten qualifiziert. Das gemeinsame #228 bleibt offen. Die Request-Key-Akzeptanz unter dem gemeinsamen #216 ist separat.
 
 So bleibt ein Abschluss innerhalb der Grenze:
 
@@ -369,14 +369,7 @@ So bleibt ein Abschluss innerhalb der Grenze:
 
 #### Rust-Befehlsplanung {#rust-completion-planning}
 
-Rust SDK 4.15.0 verwendet die gewöhnliche Grenze je Payload weiterhin als
-Gesamtgrenze für die Befehlsplanung (standardmäßig 2 MiB), bevor die höhere
-Completion-Grenze des Servers greift. Ohne externen Payload-Speicher im
-Namespace wird der veröffentlichte Fan-out mit 300 × 10 KB mit
-`external_payload_unavailable` abgelehnt. Der Worker beendet sich und der Lauf
-bleibt ausstehend. Verwenden Sie kleinere Befehlsbatches, solange die
-[Korrektur des SDK-Gesamtplaners](https://github.com/durable-workflow/sdk-rust/issues/254)
-aussteht. Dieser SDK-Pfad unterstützt die höhere Server-Grenze noch nicht.
+Rust SDK 4.16 verwendet das positive explizite Completion-Budget des Producers. Die [Kontrollen mit veröffentlichtem4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) bestehen einen Inline-Fan-out von 300 × 10 KB ohne externen Speicher, einen strukturell fehlschlagenden übergroßen Batch von 60 × 450 KB ohne teilweise gestartete Aktivitäten und eine erfolgreiche Folgeaufgabe auf demselben Worker. Fehlt das explizite Feld, behalten ältere Producer die konservative gewöhnliche Grenze. Das größere Budget gewährt keine neue Upload- oder Referenzplatzierungsberechtigung; Argumente von Activity-Continuation-Befehlen bleiben inline. Diese Kontrollen qualifizieren weder Request-Key-Retries unter dem gemeinsamen #216 noch natives Timeout-Cleanup.
 
 ## Docker-Initialisierung und Herkunft {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/de/source-hashes.json b/i18n/de/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/de/source-hashes.json
+++ b/i18n/de/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
index b7204bb57c4..a268ddfe4e9 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -90,9 +90,7 @@ si la actualización no ha terminado. Un resultado null completado es
 la [API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 para conocer la interfaz de Rust.
 
-Rust SDK 4.15.0 aún aplica el límite habitual de carga a todo el lote de
-comandos. Consulte el [límite conocido del planificador](./server-config-reference.md#rust-completion-planning)
-antes de ejecutar un fan-out grande sin almacenamiento externo de cargas.
+Rust SDK 4.16 usa el presupuesto explícito del Server `limits.max_workflow_task_completion_bytes` para planificar finalizaciones. Los productores antiguos sin ese campo conservan el límite ordinario conservador. Consulte [planificación de finalizaciones](./server-config-reference.md#rust-completion-planning) para el par cualificado con native3.9.1 y los límites de ubicación de payloads.
 
 ## Plazos de espera de condiciones y actualización de workers {#condition-wait-deadlines}
 
@@ -181,12 +179,14 @@ Cada petición, poll o despacho de tarea obtenida incrementa un contador en uno
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-Las claves del cliente son exactamente `method`, `route`, `plane`, `status_code`, `outcome`; las del worker, `task_kind`, `task_queue`, `outcome`. Los patrones revisados de rutas excluyen ID, consultas, payloads y credenciales; rutas desconocidas usan `unknown`. Las colas dependen de la aplicación: use un conjunto acotado, no una por ejecución.
+Para los pares de contador/duración anteriores: Las claves del cliente son exactamente `method`, `route`, `plane`, `status_code`, `outcome`; las del worker, `task_kind`, `task_queue`, `outcome`. Los patrones revisados de rutas excluyen ID, consultas, payloads y credenciales; rutas desconocidas usan `unknown`. Las colas dependen de la aplicación: use un conjunto acotado, no una por ejecución.
 
 Los resultados del cliente incluyen `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` y `pending` para un future cancelado. `status_code` conserva el estado HTTP decimal observado, o `none`. Los nombres de excepciones Rust no tienen que coincidir con otros SDK.
 
 Una observación del cliente incluye reintentos internos de transporte/storage admission y manejo de respuesta/payload; llamadas separadas de aplicación/worker se observan por separado. El iterador perezoso observa cada página solicitada. Los polls incluyen retry/backoff gestionados y distinguen `task`, `empty`, `backpressure`, `error`. Los resultados de tarea `completed`, `failed`, `expired` describen el despacho, no el estado terminal del workflow. Son observaciones del proceso, no contadores duraderos, unidades facturables ni latencia schedule-to-start; la pérdida abrupta del proceso puede omitir la muestra final.
 
+Rust SDK 4.16 añade el séptimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, solo con las etiquetas `task_kind` y `task_queue`. Registra en segundos el retraso entre elegibilidad y claim medido por el Server cuando el productor anuncia `claimed_task_ready_age` y suministra `ready_age_ms` válido. Los datos ausentes, inválidos o no admitidos no generan muestra; el SDK nunca inventa un cero. Los [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) cualifican las siete métricas, ready-age de workflows/actividades y el adaptador Prometheus.
+
 Para el adaptador oficial de Prometheus, active el feature opcional Cargo `metrics-prometheus`. El ejemplo usa la receta publicada de dependencias:
 
 ```toml
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index c20841ecb82..8659e9b8b49 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -348,7 +348,7 @@ Una finalización mayor se rechaza con `413 payload_too_large` y `limit_kind: wo
 
 Python SDK 2.17 y Rust SDK 4.15 incluyen el manejo del rechazo tipado. En Server 3.8.0, un control publicado de Python obtuvo `httpx.ReadError` antes de recibir HTTP 413 y dejó el workflow pendiente. El runtime nativo 3.9.1 corrige esa respuesta descartando datos de forma acotada: como máximo 64 MiB de la subida restante durante dos segundos, antes de devolver el rechazo original y cerrar la conexión. Las subidas que superen cualquiera de esos límites aún pueden sufrir errores de transporte.
 
-Python SDK 2.17.1 publicado con Server nativo 3.9.1 cualificado (linux/amd64, SQLite) supera ahora los [controles con el Worker instalado real](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro del límite, un único 413 tipado y un único fallo estructural sin actividades parciales para una finalización sobredimensionada, y después una tarea correcta en el mismo Worker. Esto cualifica ese par exacto Python/Server. PHP y Rust requieren su propia aceptación instalada; el #228 compartido sigue abierto. La aceptación de claves de solicitud del #216 compartido es independiente.
+Python SDK 2.17.1 publicado con Server nativo 3.9.1 cualificado (linux/amd64, SQLite) supera ahora los [controles con el Worker instalado real](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro del límite, un único 413 tipado y un único fallo estructural sin actividades parciales para una finalización sobredimensionada, y después una tarea correcta en el mismo Worker. Esto cualifica ese par exacto Python/Server. PHP requiere su propia aceptación instalada; Rust4.16 se cualifica abajo. El #228 compartido sigue abierto. La aceptación de claves de solicitud del #216 compartido es independiente.
 
 Para mantener una finalización dentro del límite:
 
@@ -358,14 +358,7 @@ Para mantener una finalización dentro del límite:
 
 #### Planificación de comandos en Rust {#rust-completion-planning}
 
-Rust SDK 4.15.0 sigue usando el límite habitual por carga como techo agregado
-de planificación de comandos (2 MiB por defecto), antes de la mayor capacidad
-de finalización del Server. Sin almacenamiento externo de cargas en el
-namespace, el fan-out publicado de 300 × 10 KB se rechaza con
-`external_payload_unavailable`. El worker sale y la ejecución sigue pendiente.
-Use lotes de comandos más pequeños mientras esté pendiente la
-[corrección del planificador agregado del SDK](https://github.com/durable-workflow/sdk-rust/issues/254).
-Esta ruta del SDK aún no implementa la mayor capacidad del Server.
+Rust SDK 4.16 usa el presupuesto positivo explícito de finalización anunciado por el productor. Los [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) superan fan-out inline de 300 × 10 KB sin almacenamiento externo, un lote sobredimensionado de 60 × 450 KB que falla estructuralmente sin actividades parciales y una tarea posterior correcta en el mismo Worker. Sin el campo explícito, los productores antiguos conservan el límite ordinario conservador. El presupuesto mayor no concede nuevos permisos de subida o colocación de referencias; los argumentos de comandos de continuación de actividades siguen inline. Estos controles no cualifican los reintentos con clave del #216 compartido ni la limpieza por timeout nativa.
 
 ## Inicialización de Docker y procedencia {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/es/source-hashes.json b/i18n/es/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/es/source-hashes.json
+++ b/i18n/es/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 938eddfe7c6..ca55c001473 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -147,9 +147,7 @@ inachevée. Un résultat null terminé est `Ok(Value::Null)`. Les accusés conse
 le `update_status` explicite. Consultez l'[API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 pour l'interface Rust.
 
-Rust SDK 4.15.0 applique encore le plafond ordinaire de charge utile au lot
-entier de commandes. Consultez la [limite connue du planificateur](./server-config-reference.md#rust-completion-planning)
-avant un grand fan-out sans stockage externe des charges utiles.
+Rust SDK 4.16 utilise le budget explicite du Server `limits.max_workflow_task_completion_bytes` pour planifier les finalisations. Les anciens producteurs sans ce champ conservent le plafond ordinaire conservateur. Consultez la [planification des finalisations](./server-config-reference.md#rust-completion-planning) pour le couple qualifié avec native3.9.1 et les limites de placement des payloads.
 
 ## Échéances des attentes de condition et mise à niveau des workers {#condition-wait-deadlines}
 
@@ -239,12 +237,14 @@ Chaque requête, poll ou traitement d’une tâche acquise incrémente un compte
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-Les clés client sont exactement `method`, `route`, `plane`, `status_code`, `outcome` ; celles du worker sont `task_kind`, `task_queue`, `outcome`. Les modèles de route revus excluent ID, chaînes de requête, payloads et secrets ; les chemins inconnus utilisent `unknown`. Les noms de file dépendent de l’application : gardez un ensemble borné, pas une file par exécution.
+Pour les paires compteur/durée ci-dessus : Les clés client sont exactement `method`, `route`, `plane`, `status_code`, `outcome` ; celles du worker sont `task_kind`, `task_queue`, `outcome`. Les modèles de route revus excluent ID, chaînes de requête, payloads et secrets ; les chemins inconnus utilisent `unknown`. Les noms de file dépendent de l’application : gardez un ensemble borné, pas une file par exécution.
 
 Les résultats client incluent `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` et `pending` pour un future annulé. `status_code` conserve le statut HTTP décimal observé, sinon `none`. Les noms d’exceptions Rust peuvent différer de ceux d’autres SDK.
 
 Une observation client inclut les réessais internes de transport/storage admission et le traitement réponse/payload ; les appels distincts gérés par l’application/worker sont séparés. L’itérateur paresseux observe chaque page chargée. Les polls incluent retry/backoff gérés et distinguent `task`, `empty`, `backpressure`, `error`. Les résultats task `completed`, `failed`, `expired` décrivent le traitement, pas l’état terminal du workflow. Ce sont des observations de processus, pas des comptes durables, unités facturables ou latences schedule-to-start ; une perte brutale peut omettre l’échantillon final.
 
+Rust SDK 4.16 ajoute le septième instrument, `durable_workflow_worker_task_schedule_to_start_seconds`, avec les seules étiquettes `task_kind` et `task_queue`. Il enregistre en secondes le délai entre éligibilité et claim mesuré par le Server lorsque le producteur annonce `claimed_task_ready_age` et fournit un `ready_age_ms` valide. Une donnée absente, invalide ou non prise en charge ne produit aucun échantillon ; le SDK n’invente jamais un zéro. Les [contrôles publiés4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifient les sept métriques, le ready-age workflow/activité et l’adaptateur Prometheus.
+
 Pour l’adaptateur officiel Prometheus, activez le feature Cargo facultatif `metrics-prometheus`. Cet exemple utilise les dépendances publiées :
 
 ```toml
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 0bdb959c1c1..bfd25af2521 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -348,7 +348,7 @@ Un achèvement plus grand est refusé avec `413 payload_too_large` et `limit_kin
 
 Python SDK 2.17 et Rust SDK 4.15 gèrent le refus typé. Sur Server 3.8.0, un contrôle Python publié rencontrait `httpx.ReadError` avant HTTP 413 et laissait le workflow en attente. Le runtime natif 3.9.1 corrige cette réponse par une lecture puis un abandon bornés du reste de la requête : au plus 64 MiB pendant deux secondes avant de renvoyer le refus original et fermer la connexion. Au-delà de l’une de ces bornes, des erreurs de transport restent possibles.
 
-Le SDK Python 2.17.1 publié avec le Server natif 3.9.1 qualifié (linux/amd64, SQLite) réussit désormais les [contrôles sur le Worker réellement installé](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512) : fan-out de 300 × 10 KB dans la limite, un seul 413 typé et un seul échec structurel sans activité partielle pour une finalisation trop grande, puis une tâche réussie sur le même Worker. Cela qualifie ce couple exact Python/Server. PHP et Rust nécessitent leurs propres preuves sur installation ; le #228 partagé reste ouvert. L’acceptation des clés de requête du #216 partagé est distincte.
+Le SDK Python 2.17.1 publié avec le Server natif 3.9.1 qualifié (linux/amd64, SQLite) réussit désormais les [contrôles sur le Worker réellement installé](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512) : fan-out de 300 × 10 KB dans la limite, un seul 413 typé et un seul échec structurel sans activité partielle pour une finalisation trop grande, puis une tâche réussie sur le même Worker. Cela qualifie ce couple exact Python/Server. PHP nécessite sa propre preuve sur installation ; Rust4.16 est qualifié ci-dessous. Le #228 partagé reste ouvert. L’acceptation des clés de requête du #216 partagé est distincte.
 
 Pour garder un achèvement sous la limite :
 
@@ -358,14 +358,7 @@ Pour garder un achèvement sous la limite :
 
 #### Planification des commandes Rust {#rust-completion-planning}
 
-Rust SDK 4.15.0 utilise encore la limite ordinaire par charge utile comme
-plafond agrégé de planification des commandes (2 MiB par défaut), avant la
-capacité de complétion supérieure du Server. Sans stockage externe des charges
-utiles dans l'espace de noms, le fan-out publié de 300 × 10 KB est refusé avec
-`external_payload_unavailable`. Le worker s'arrête et l'exécution reste en
-attente. Utilisez des lots plus petits en attendant la
-[correction du planificateur agrégé du SDK](https://github.com/durable-workflow/sdk-rust/issues/254).
-Ce chemin du SDK ne fournit pas encore la capacité supérieure du Server.
+Rust SDK 4.16 utilise le budget de finalisation positif et explicite annoncé par le producteur. Les [contrôles publiés4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) réussissent un fan-out inline de 300 × 10 KB sans stockage externe, un lot trop grand de 60 × 450 KB échouant structurellement sans activité partielle, puis une tâche réussie sur le même Worker. Sans le champ explicite, les anciens producteurs gardent le plafond ordinaire conservateur. Le budget supérieur n’accorde aucun droit supplémentaire de téléversement ou placement de références ; les arguments des commandes de continuation d’activité restent inline. Ces contrôles ne qualifient ni les reprises avec clé du #216 partagé ni le nettoyage natif après timeout.
 
 ## Initialisation Docker et provenance {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/fr/source-hashes.json b/i18n/fr/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/fr/source-hashes.json
+++ b/i18n/fr/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 1bf5ecccde3..dfd6e9ced6a 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -83,7 +83,7 @@ Server はメジャー `1` 内で Worker プロトコルヘッダーをネゴシ
 
 Rust SDK 4.15 では、受け付け済みの更新を ID で読み取り、再送信を避ける `Client::update_outcome` と `Client::update_outcome_receipt` が追加されました。これらには `capabilities.update_outcome_reads`（native Server 3.6.0 以降）が必要です。`update_outcome` は未完了の更新に対して `Error::UpdateStillPending` を返します。完了した null の結果は `Ok(Value::Null)` です。レシートは明示的な `update_status` を保持します。Rust のインターフェースは [Client API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome) を参照してください。
 
-Rust SDK 4.15.0 は、通常のペイロード上限をコマンドバッチ全体に適用します。外部ペイロードストレージなしで大きなファンアウトを実行する前に、[既知の計画上限](./server-config-reference.md#rust-completion-planning)を確認してください。
+Rust SDK 4.16 は Server が明示する `limits.max_workflow_task_completion_bytes` 予算を完了計画に使います。このフィールドがない古い producer では、保守的な通常の上限を維持します。検証済み native3.9.1 との組み合わせと payload 配置の制限は[完了計画](./server-config-reference.md#rust-completion-planning)を参照してください。
 
 ## 条件待機の期限と Worker のアップグレード {#condition-wait-deadlines}
 
@@ -169,12 +169,14 @@ Ok(())
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-クライアントのタグキーは `method`、`route`、`plane`、`status_code`、`outcome`、worker は `task_kind`、`task_queue`、`outcome` のみです。検証済みルートのプレースホルダーは ID、クエリ文字列、payload、資格情報を含まず、不明なパスは `unknown` です。キュー名はアプリが制御し、実行ごとに作らず有限の集合にします。
+上記のカウンターと処理時間の組では、クライアントのタグキーは `method`、`route`、`plane`、`status_code`、`outcome`、worker は `task_kind`、`task_queue`、`outcome` のみです。検証済みルートのプレースホルダーは ID、クエリ文字列、payload、資格情報を含まず、不明なパスは `unknown` です。キュー名はアプリが制御し、実行ごとに作らず有限の集合にします。
 
 クライアントの outcome は `ok`、`http_error`、`bridge_rejected`、`TransportError`、`TimeoutError`、`SdkError` と、キャンセルされた future の `pending` を含みます。`status_code` は観測した10進 HTTP 状態を保持し、なければ `none` です。Rust の例外名は他 SDK と同じとは限りません。
 
 クライアントの1観測には内部 transport/storage admission の再試行と応答/payload 処理を含み、アプリや worker が管理する別呼び出しは別観測です。遅延イテレーターは取得ページごとに観測します。worker poll は管理された retry/backoff を含み、`task`、`empty`、`backpressure`、`error` を区別します。task 結果の `completed`、`failed`、`expired` は処理結果であり workflow の終端状態ではありません。これはプロセス観測で、永続カウント、課金単位、schedule-to-start 遅延ではなく、突然のプロセス喪失で最後のサンプルが失われる場合があります。
 
+Rust SDK 4.16 は 7 番目の計測器 `durable_workflow_worker_task_schedule_to_start_seconds` を追加し、タグは `task_kind` と `task_queue` のみです。producer が `claimed_task_ready_age` を広告し、有効な `ready_age_ms` を返す場合に、Server が計測した実行可能時点から claim までの遅延を秒単位で記録します。データの欠落、不正、非対応時にはサンプルを出さず、ゼロを捏造しません。[公開済み4.16/native3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、7 メトリクスすべて、workflow/Activity の ready-age、Prometheus アダプターを確認しています。
+
 公式 Prometheus adapter には任意の Cargo feature `metrics-prometheus` を有効にします。この例は公開済みの依存関係設定を使います。
 
 ```toml
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 71d6997ac2d..db0d2e9505f 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -334,7 +334,7 @@ SDK のプランナーは、通常の上限より小さくても、公開され
 
 Python SDK 2.17 と Rust SDK 4.15 には型付き拒否の処理があります。Server 3.8.0 の公開済み Python 検証では HTTP 413 を受け取る前に `httpx.ReadError` が発生し、workflow が保留されました。native 3.9.1 は、残りのアップロードを最大 64 MiB、最大 2 秒間だけ破棄してから元の拒否を返し、接続を閉じることで応答経路を修正します。どちらかの境界を超えるアップロードでは、引き続きトランスポートエラーが起こり得ます。
 
-公開済み Python SDK 2.17.1 と検証済み native Server 3.9.1（linux/amd64、SQLite）は、[実際にインストールした Worker の検証](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)に合格しました。上限内の 300 × 10 KB fan-out、大きすぎる完了に対する型付き 413 が 1 回と構造的失敗が 1 回、部分的な Activity がゼロ、その後の同じ Worker でのタスク成功を確認しています。この特定の Python/Server 組み合わせの検証です。PHP と Rust にはそれぞれのインストール済み検証が必要で、共有 #228 は未完了です。共有 #216 のリクエストキー検証は別です。
+公開済み Python SDK 2.17.1 と検証済み native Server 3.9.1（linux/amd64、SQLite）は、[実際にインストールした Worker の検証](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)に合格しました。上限内の 300 × 10 KB fan-out、大きすぎる完了に対する型付き 413 が 1 回と構造的失敗が 1 回、部分的な Activity がゼロ、その後の同じ Worker でのタスク成功を確認しています。この特定の Python/Server 組み合わせの検証です。PHP には独自のインストール済み検証が必要です。Rust4.16 の検証は下記に示します。共有 #228 は未完了です。共有 #216 のリクエストキー検証は別です。
 
 完了を上限内に収めるには：
 
@@ -344,7 +344,7 @@ Python SDK 2.17 と Rust SDK 4.15 には型付き拒否の処理があります
 
 #### Rust のコマンド計画 {#rust-completion-planning}
 
-Rust SDK 4.15.0 は、Server のより大きな完了上限より先に、通常のペイロード上限をコマンド計画全体の上限として適用します（既定は 2 MiB）。名前空間に外部ペイロードストレージがない場合、公開済みの 300 × 10 KB ファンアウトは `external_payload_unavailable` で拒否され、Worker が終了し、実行は保留中のままになります。[SDK の集約計画の修正](https://github.com/durable-workflow/sdk-rust/issues/254)が完了するまでは、小さなコマンドバッチを使ってください。この SDK の経路は、Server のより大きな上限にはまだ対応していません。
+Rust SDK 4.16 は producer が広告した明示的な正の完了予算を使います。[公開済み4.16/native3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、外部ストレージなしの 300 × 10 KB inline fan-out、部分的な Activity ゼロで構造的に失敗する上限超過の 60 × 450 KB バッチ、その後の同じ Worker でのタスク成功を確認しています。明示的なフィールドがなければ、古い producer は保守的な通常の上限を維持します。予算が増えても、アップロードや参照配置の追加権限は得られず、Activity continuation のコマンド引数は inline のままです。この検証は共有 #216 のキー付き再試行や native のタイムアウト清理を確認するものではありません。
 
 ## Docker の初期化と出所情報 {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/ja/source-hashes.json b/i18n/ja/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/ja/source-hashes.json
+++ b/i18n/ja/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 34aab6678d6..64a8eb58030 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -141,9 +141,7 @@ resultado null concluído é `Ok(Value::Null)`. Os recibos preservam o
 `update_status` explícito. Veja a [API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 para a interface de Rust.
 
-O Rust SDK 4.15.0 ainda aplica o teto comum de payload ao lote inteiro de
-comandos. Veja o [limite conhecido do planejador](./server-config-reference.md#rust-completion-planning)
-antes de um fan-out grande sem armazenamento externo de payloads.
+Rust SDK 4.16 usa o orçamento explícito do Server `limits.max_workflow_task_completion_bytes` para planejar conclusões. Produtores antigos sem esse campo mantêm o limite comum conservador. Veja o [planejamento de conclusões](./server-config-reference.md#rust-completion-planning) para o par qualificado com native3.9.1 e os limites de posicionamento de payloads.
 
 ## Prazos de espera de condições e atualização de workers {#condition-wait-deadlines}
 
@@ -231,12 +229,14 @@ Cada requisição, poll ou despacho de tarefa obtida incrementa um contador em u
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-As chaves do cliente são exatamente `method`, `route`, `plane`, `status_code`, `outcome`; as do worker, `task_kind`, `task_queue`, `outcome`. Padrões revisados de rotas excluem IDs, consultas, payloads e credenciais; caminhos desconhecidos usam `unknown`. Nomes de fila pertencem à aplicação: use um conjunto limitado, não uma fila por execução.
+Para os pares de contador/duração acima: As chaves do cliente são exatamente `method`, `route`, `plane`, `status_code`, `outcome`; as do worker, `task_kind`, `task_queue`, `outcome`. Padrões revisados de rotas excluem IDs, consultas, payloads e credenciais; caminhos desconhecidos usam `unknown`. Nomes de fila pertencem à aplicação: use um conjunto limitado, não uma fila por execução.
 
 Resultados do cliente incluem `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` e `pending` para um future cancelado. `status_code` mantém o status HTTP decimal observado ou `none`. Os nomes de exceções Rust podem diferir de outros SDKs.
 
 Uma observação do cliente inclui repetições internas de transporte/storage admission e tratamento de resposta/payload; chamadas separadas da aplicação/worker são observadas separadamente. Um iterador preguiçoso observa cada página buscada. Polls incluem retry/backoff gerenciados e distinguem `task`, `empty`, `backpressure`, `error`. Resultados `completed`, `failed`, `expired` descrevem o despacho, não o estado terminal do workflow. São observações de processo, não contagens duráveis, unidades de cobrança ou latência schedule-to-start; perda abrupta pode omitir a amostra final.
 
+Rust SDK 4.16 adiciona o sétimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, apenas com as tags `task_kind` e `task_queue`. Ele registra em segundos a demora entre elegibilidade e claim medida pelo Server quando o produtor anuncia `claimed_task_ready_age` e fornece `ready_age_ms` válido. Dados ausentes, inválidos ou não suportados não geram amostra; o SDK nunca inventa zero. Os [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualificam as sete métricas, ready-age de workflow/atividade e o adaptador Prometheus.
+
 Para o adaptador oficial Prometheus, habilite o feature Cargo opcional `metrics-prometheus`. O exemplo usa a receita publicada de dependências:
 
 ```toml
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index b732d952314..c99a77a36b1 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -348,7 +348,7 @@ Uma conclusão maior é recusada com `413 payload_too_large` e `limit_kind: work
 
 Python SDK 2.17 e Rust SDK 4.15 incluem tratamento para a recusa tipada. No Server 3.8.0, um controle Python publicado recebeu `httpx.ReadError` antes do HTTP 413 e deixou o workflow pendente. O runtime nativo 3.9.1 corrige a resposta descartando dados de forma limitada: no máximo 64 MiB da carga restante por até dois segundos, antes de devolver a recusa original e fechar a conexão. Uploads que ultrapassem qualquer limite ainda podem ter erros de transporte.
 
-O Python SDK 2.17.1 publicado com o Server nativo 3.9.1 qualificado (linux/amd64, SQLite) agora passa nos [controles com Worker realmente instalado](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro do limite, um único 413 tipado e uma única falha estrutural sem atividades parciais para uma conclusão grande demais, e depois uma tarefa bem-sucedida no mesmo Worker. Isso qualifica esse par exato Python/Server. PHP e Rust exigem sua própria aceitação instalada; o #228 compartilhado continua aberto. A aceitação de chaves de requisição do #216 compartilhado é separada.
+O Python SDK 2.17.1 publicado com o Server nativo 3.9.1 qualificado (linux/amd64, SQLite) agora passa nos [controles com Worker realmente instalado](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro do limite, um único 413 tipado e uma única falha estrutural sem atividades parciais para uma conclusão grande demais, e depois uma tarefa bem-sucedida no mesmo Worker. Isso qualifica esse par exato Python/Server. PHP exige sua própria aceitação instalada; Rust4.16 está qualificado abaixo. O #228 compartilhado continua aberto. A aceitação de chaves de requisição do #216 compartilhado é separada.
 
 Para manter uma conclusão dentro do limite:
 
@@ -358,14 +358,7 @@ Para manter uma conclusão dentro do limite:
 
 #### Planejamento de comandos em Rust {#rust-completion-planning}
 
-O Rust SDK 4.15.0 ainda usa o limite comum por payload como teto agregado do
-planejamento de comandos (2 MiB por padrão), antes da capacidade maior de
-conclusão do Server. Sem armazenamento externo de payloads no namespace, o
-fan-out publicado de 300 × 10 KB é recusado com `external_payload_unavailable`.
-O worker encerra e a execução continua pendente. Use lotes menores enquanto a
-[correção do planejador agregado do SDK](https://github.com/durable-workflow/sdk-rust/issues/254)
-estiver pendente. Esse caminho do SDK ainda não implementa a capacidade maior
-do Server.
+Rust SDK 4.16 usa o orçamento positivo explícito de conclusão anunciado pelo produtor. Os [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) passam fan-out inline de 300 × 10 KB sem armazenamento externo, um lote grande demais de 60 × 450 KB que falha estruturalmente sem atividades parciais e uma tarefa posterior bem-sucedida no mesmo Worker. Sem o campo explícito, produtores antigos mantêm o limite comum conservador. O orçamento maior não concede nova autorização de upload ou referências; argumentos de comandos de continuação de atividades permanecem inline. Esses controles não qualificam retries com chave do #216 compartilhado nem limpeza nativa por timeout.
 
 ## Inicialização do Docker e procedência {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/pt-BR/source-hashes.json b/i18n/pt-BR/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/pt-BR/source-hashes.json
+++ b/i18n/pt-BR/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 4409fa03654..4884b186046 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -141,9 +141,7 @@ Rust SDK 4.15 додає `Client::update_outcome` і
 null має вигляд `Ok(Value::Null)`. Підтвердження зберігають явний `update_status`.
 Інтерфейс Rust описано в [API Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome).
 
-Rust SDK 4.15.0 ще застосовує звичайну межу payload до всього пакета команд.
-Див. [відоме обмеження планувальника](./server-config-reference.md#rust-completion-planning)
-перед великим fan-out без зовнішнього сховища payload.
+Rust SDK 4.16 використовує явний бюджет Server `limits.max_workflow_task_completion_bytes` для планування завершень. Старіші producer без цього поля зберігають консервативну звичайну межу. Дивіться [планування завершень](./server-config-reference.md#rust-completion-planning) щодо кваліфікованої пари з native3.9.1 та меж розміщення payload.
 
 ## Строки очікування умови та оновлення worker {#condition-wait-deadlines}
 
@@ -231,12 +229,14 @@ Ok(())
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-Ключі тегів клієнта — саме `method`, `route`, `plane`, `status_code`, `outcome`; worker — `task_kind`, `task_queue`, `outcome`. Перевірені шаблони маршрутів не містять ID, query string, payload чи credentials; невідомі шляхи мають `unknown`. Назви черг задає застосунок: використовуйте обмежений набір, а не чергу на кожен запуск.
+Для наведених пар лічильник/тривалість: Ключі тегів клієнта — саме `method`, `route`, `plane`, `status_code`, `outcome`; worker — `task_kind`, `task_queue`, `outcome`. Перевірені шаблони маршрутів не містять ID, query string, payload чи credentials; невідомі шляхи мають `unknown`. Назви черг задає застосунок: використовуйте обмежений набір, а не чергу на кожен запуск.
 
 Результати клієнта включають `ok`, `http_error`, `bridge_rejected`, `TransportError`, `TimeoutError`, `SdkError` і `pending` для скасованого future. `status_code` зберігає спостережений десятковий HTTP-статус, інакше `none`. Назви результатів винятків Rust не обов’язково збігаються з іншими SDK.
 
 Одне клієнтське спостереження включає внутрішні повтори транспорту/storage admission та обробку відповіді/payload; окремі виклики застосунку чи worker рахуються окремо. Лінивий ітератор спостерігає кожну отриману сторінку. Poll worker включає керовані retry/backoff і розрізняє `task`, `empty`, `backpressure`, `error`. Результати task `completed`, `failed`, `expired` описують обробку dispatch, а не завершення workflow. Це спостереження процесу, не durable-лічильники, одиниці оплати чи schedule-to-start latency; аварійна втрата процесу може втратити останній зразок.
 
+Rust SDK 4.16 додає сьомий інструмент `durable_workflow_worker_task_schedule_to_start_seconds` лише з тегами `task_kind` і `task_queue`. Він записує в секундах виміряну Server затримку від готовності до claim, коли producer оголошує `claimed_task_ready_age` і надає коректний `ready_age_ms`. Відсутні, некоректні чи непідтримувані дані не дають зразка; SDK ніколи не вигадує нуль. [Опубліковані контролі4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) кваліфікують усі сім метрик, ready-age workflow/активностей і адаптер Prometheus.
+
 Для офіційного Prometheus adapter увімкніть необов’язковий Cargo feature `metrics-prometheus`. Цей приклад використовує опублікований рецепт залежностей:
 
 ```toml
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index a9db5302cf5..8807760dd1f 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -448,7 +448,7 @@ runtime також діють. Рядок ID workflow стосується ок
 
 Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану відмову. На Server 3.8.0 опублікований контроль Python отримав `httpx.ReadError` до HTTP 413 і залишив workflow в очікуванні. Нативний runtime 3.9.1 виправляє відповідь обмеженим відкиданням решти запиту: щонайбільше 64 MiB за щонайбільше дві секунди перед початковою відмовою та закриттям з’єднання. Завантаження поза будь-якою з цих меж і далі можуть мати транспортні помилки.
 
-Опублікований Python SDK 2.17.1 із кваліфікованим нативним Server 3.9.1 (linux/amd64, SQLite) тепер проходить [контролі реально встановленого Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out 300 × 10 KB у межах бюджету, одна типізована 413 і один структурний збій без часткових активностей для завеликого завершення, а потім успішне завдання на тому самому Worker. Це кваліфікує саме цю пару Python/Server. PHP і Rust потребують власних перевірок установлених пакетів; спільне #228 залишається відкритим. Перевірка ключів запитів у спільному #216 є окремою.
+Опублікований Python SDK 2.17.1 із кваліфікованим нативним Server 3.9.1 (linux/amd64, SQLite) тепер проходить [контролі реально встановленого Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out 300 × 10 KB у межах бюджету, одна типізована 413 і один структурний збій без часткових активностей для завеликого завершення, а потім успішне завдання на тому самому Worker. Це кваліфікує саме цю пару Python/Server. PHP потребує власної перевірки встановленого пакета; Rust4.16 кваліфіковано нижче. Спільне #228 залишається відкритим. Перевірка ключів запитів у спільному #216 є окремою.
 
 Щоб завершення вкладалося в ліміт:
 
@@ -458,13 +458,7 @@ Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану ві
 
 #### Планування команд Rust {#rust-completion-planning}
 
-Rust SDK 4.15.0 ще використовує звичайне обмеження одного payload як сумарну
-межу планування команд (типово 2 MiB), до вищої межі запитів завершення Server.
-Без зовнішнього сховища payload у namespace опублікований fan-out із
-300 × 10 KB відхиляється з `external_payload_unavailable`. Worker завершує
-роботу, а запуск залишається в очікуванні. Використовуйте менші пакети команд,
-поки очікується [виправлення сумарного планувальника SDK](https://github.com/durable-workflow/sdk-rust/issues/254).
-Цей шлях SDK ще не реалізує вищу межу Server.
+Rust SDK 4.16 використовує явний позитивний бюджет завершення, оголошений producer. [Опубліковані контролі4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) проходять inline fan-out 300 × 10 KB без зовнішнього сховища, завеликий пакет 60 × 450 KB зі структурним збоєм без часткових активностей і успішне наступне завдання на тому самому Worker. Без явного поля старіші producer зберігають консервативну звичайну межу. Більший бюджет не надає нових прав на завантаження чи розміщення посилань; аргументи команд продовження активності залишаються inline. Ці контролі не кваліфікують повтори з ключами зі спільного #216 або нативне очищення за тайм-аутом.
 
 ## Docker bootstrap та походження пакета {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/uk/source-hashes.json b/i18n/uk/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/uk/source-hashes.json
+++ b/i18n/uk/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 52f56dbf41e..31435398e50 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -81,7 +81,7 @@ Server 在主版本 `1` 内协商 Worker 协议头：公布 `1.N` 的 Server 仅
 
 Rust SDK 4.15 新增 `Client::update_outcome` 和 `Client::update_outcome_receipt`，用于按 ID 读取已接受的更新，不重新提交。这些方法要求 `capabilities.update_outcome_reads`（native Server 3.6.0 及更高版本）。`update_outcome` 对尚未完成的更新返回 `Error::UpdateStillPending`。已完成的 null 结果为 `Ok(Value::Null)`。回执保留明确的 `update_status`。Rust 接口见 [Client API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)。
 
-Rust SDK 4.15.0 仍对整个命令批次应用普通载荷上限。在没有外部载荷存储时执行较大的扇出之前，请查看[已知规划器上限](./server-config-reference.md#rust-completion-planning)。
+Rust SDK 4.16 使用 Server 显式提供的 `limits.max_workflow_task_completion_bytes` 预算规划完成请求。没有该字段的旧 producer 继续使用保守的普通上限。经过验证的 native3.9.1 组合及 payload 位置限制见[完成规划](./server-config-reference.md#rust-completion-planning)。
 
 ## 条件等待期限与 Worker 升级 {#condition-wait-deadlines}
 
@@ -164,12 +164,14 @@ Ok(())
 | `durable_workflow_worker_polls` | `durable_workflow_worker_poll_duration_seconds` |
 | `durable_workflow_worker_tasks` | `durable_workflow_worker_task_duration_seconds` |
 
-客户端标签键恰为 `method`、`route`、`plane`、`status_code`、`outcome`；worker 键为 `task_kind`、`task_queue`、`outcome`。经审查的路由占位符不含 ID、查询串、payload 或凭据；未知路径使用 `unknown`。队列名由应用控制，应使用有限集合，不要为每次运行创建队列名。
+对于上述计数器/耗时组合，客户端标签键恰为 `method`、`route`、`plane`、`status_code`、`outcome`；worker 键为 `task_kind`、`task_queue`、`outcome`。经审查的路由占位符不含 ID、查询串、payload 或凭据；未知路径使用 `unknown`。队列名由应用控制，应使用有限集合，不要为每次运行创建队列名。
 
 客户端结果包括 `ok`、`http_error`、`bridge_rejected`、`TransportError`、`TimeoutError`、`SdkError`，取消的 future 使用 `pending`。`status_code` 保留观测到的十进制 HTTP 状态，否则为 `none`。Rust 异常结果名称不必与其他 SDK 相同。
 
 一次客户端观测包含内部传输/storage admission 重试及响应/payload 处理；应用或 worker 管理的独立调用分别计量。惰性迭代器按所请求的每页观测。worker poll 包含管理的 retry/backoff，区分 `task`、`empty`、`backpressure`、`error`。任务结果 `completed`、`failed`、`expired` 描述任务处理，不表示工作流终态。这是进程观测，不是持久计数、计费单位或 schedule-to-start 延迟；进程突然丢失可能遗漏最终样本。
 
+Rust SDK 4.16 添加第七个指标 `durable_workflow_worker_task_schedule_to_start_seconds`，仅带 `task_kind` 和 `task_queue` 标签。当 producer 公布 `claimed_task_ready_age` 并提供有效的 `ready_age_ms` 时，它以秒记录 Server 计量的“可执行到 claim”延迟。数据缺失、无效或不受支持时不产生样本；SDK 不会编造零值。[已发布4.16/native3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）验证了全部七个指标、workflow/activity ready-age 观测和 Prometheus 适配器。
+
 使用官方 Prometheus 适配器时，启用可选 Cargo feature `metrics-prometheus`。示例采用已发布的依赖配置：
 
 ```toml
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 949b356b6bb..22c81a70f4e 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -334,7 +334,7 @@ SDK 规划器必须遵守公布的正整数上限，即使它低于普通上限
 
 Python SDK 2.17 和 Rust SDK 4.15 包含类型化拒绝处理。Server 3.8.0 的已发布 Python 验证在收到 HTTP 413 前遇到 `httpx.ReadError`，使 workflow 保持待定。原生 3.9.1 通过有界丢弃请求余下数据修复此响应路径：最多 64 MiB、最多两秒，然后返回原始拒绝并关闭连接。超出任一边界的上传仍可能遇到传输错误。
 
-已发布的 Python SDK 2.17.1 与经过验证的原生 Server 3.9.1（linux/amd64、SQLite）现已通过[实际安装 Worker 的验证](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)：预算内 300 × 10 KB fan-out；过大的完成请求只产生一次类型化 413 和一次结构性失败，部分 activity 为零；随后同一 Worker 成功执行后续任务。此结果只验证这个确切的 Python/Server 组合。PHP 和 Rust 仍需各自的安装后验证；共享 #228 仍未关闭。共享 #216 的请求键验证是独立的。
+已发布的 Python SDK 2.17.1 与经过验证的原生 Server 3.9.1（linux/amd64、SQLite）现已通过[实际安装 Worker 的验证](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)：预算内 300 × 10 KB fan-out；过大的完成请求只产生一次类型化 413 和一次结构性失败，部分 activity 为零；随后同一 Worker 成功执行后续任务。此结果只验证这个确切的 Python/Server 组合。PHP 仍需独立的安装后验证；Rust4.16 的验证如下。共享 #228 仍未关闭。共享 #216 的请求键验证是独立的。
 
 要让完成请求保持在上限之内：
 
@@ -344,7 +344,7 @@ Python SDK 2.17 和 Rust SDK 4.15 包含类型化拒绝处理。Server 3.8.0 的
 
 #### Rust 命令规划 {#rust-completion-planning}
 
-Rust SDK 4.15.0 仍将普通单个载荷上限作为命令规划的总上限（默认为 2 MiB），先于 Server 更大的完成请求上限生效。如果命名空间没有外部载荷存储，已发布的 300 × 10 KB 扇出会以 `external_payload_unavailable` 被拒绝，Worker 退出，运行保持待处理状态。在 [SDK 总量规划器修复](https://github.com/durable-workflow/sdk-rust/issues/254)完成之前，请使用更小的命令批次。此 SDK 路径尚未实现 Server 更大的上限。
+Rust SDK 4.16 使用 producer 公布的显式正整数完成预算。[已发布4.16/native3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）通过了无外部存储的 300 × 10 KB inline fan-out、过大的 60 × 450 KB 批次产生结构性失败且部分 activity 为零、随后同一 Worker 的后续任务成功。缺少显式字段时，旧 producer 继续使用保守的普通上限。更大的预算不授予新上传权限或引用位置权限；activity continuation 命令参数仍须 inline。这些验证不代表共享 #216 的请求键重试或原生超时清理已通过。
 
 ## Docker 初始化与来源信息 {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/zh-Hans/source-hashes.json b/i18n/zh-Hans/source-hashes.json
index 7b298af1d22..01a6ab2308e 100644
--- a/i18n/zh-Hans/source-hashes.json
+++ b/i18n/zh-Hans/source-hashes.json
@@ -87,9 +87,9 @@
   "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
-  "polyglot/rust.md": "e768d43c38be76b22440910aa97d61897b392321f106dd2fe7461399a13a99c9",
+  "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "db751ab94bd0f826b6a6a7d6d00f769de6945f312a650cce2d2fdbb157b39abf",
+  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/static/stable-releases.json b/static/stable-releases.json
index 76d1ce6ddc5..43219720623 100644
--- a/static/stable-releases.json
+++ b/static/stable-releases.json
@@ -4,20 +4,20 @@
   "updated_at": "2026-11-13",
   "artifacts": {
     "cli": "2.8.0",
-    "helm-chart": "1.6.0",
+    "helm-chart": "1.7.0",
     "sdk-php": "3.18.0",
     "sdk-python": "2.17.1",
-    "sdk-rust": "4.15.0",
-    "server": "3.8.0",
+    "sdk-rust": "4.16.0",
+    "server": "3.9.1",
     "waterline": "2.18.0",
     "workflow": "2.28.0"
   },
   "helm_chart": {
-    "app_version": "3.8.0",
+    "app_version": "3.9.1",
     "repository": "oci://ghcr.io/durable-workflow/charts/durable-workflow",
-    "oci_manifest_digest": "sha256:a031c6619fb17dc9f1ccc5cfbe19a2bec7becaf72b49830c72b670586b82dc96",
-    "package_digest": "sha256:84435607912b6400f39fb618c4e0644ac922a6c134ac3187a2ff3eef67fb87de",
-    "source_commit": "257d0af591f25d89ad3335aae31d3557c5977888",
-    "qualification_url": "https://github.com/durable-workflow/server/actions/runs/43331170106"
+    "oci_manifest_digest": "sha256:15e10c2296a5de518f5312db868144ab6c07a41f20faa7ff47a2c7b7551a6020",
+    "package_digest": "sha256:9c677b556b992ded56f21523b086702b23c66744c87a607843aa8259d748bab6",
+    "source_commit": "df64a66fa59fdcb25e4beb058e7fdc3ea957b0c8",
+    "qualification_url": "https://github.com/durable-workflow/server/actions/runs/43431846246"
   }
 }

From e49e3e90aa08c6b520d192f31f6b4d0f930c3c61 Mon Sep 17 00:00:00 2001
From: Richard McDaniel <1130888+rmcdaniel@users.noreply.github.com>
Date: Fri, 13 Nov 2026 13:58:47 +0000
Subject: [PATCH 6/6] Scope planner validation to Rust and correct Python
 receipt returns

---
 docs/polyglot/python.md                                  | 9 +++++++--
 docs/polyglot/server-config-reference.md                 | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/de/source-hashes.json                               | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/es/source-hashes.json                               | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/fr/source-hashes.json                               | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/ja/source-hashes.json                               | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/pt-BR/source-hashes.json                            | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/uk/source-hashes.json                               | 4 ++--
 .../current/polyglot/python.md                           | 6 ++++--
 .../current/polyglot/rust.md                             | 4 ++--
 .../current/polyglot/server-config-reference.md          | 6 +++---
 i18n/zh-Hans/source-hashes.json                          | 4 ++--
 30 files changed, 86 insertions(+), 67 deletions(-)

diff --git a/docs/polyglot/python.md b/docs/polyglot/python.md
index c9c090ba258..14d3f610ad2 100644
--- a/docs/polyglot/python.md
+++ b/docs/polyglot/python.md
@@ -461,8 +461,8 @@ end-to-end rollout walkthrough; the CLI mirrors of these methods are
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, auth/server errors |
 | `await client.get_history(workflow_id, run_id)` | decoded history payload | `WorkflowNotFound`, auth/server errors |
 | `await client.export_history(workflow_id, run_id)` | decoded archival history payload | `WorkflowNotFound`, auth/server errors |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, auth/server errors |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | decoded query result | `QueryFailed`, `WorkflowNotFound`, auth/server errors |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | admission receipt (`dict`) | `WorkflowNotFound`, `InvalidArgument`, auth/server errors |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | query receipt (`dict`) | `QueryFailed`, `WorkflowNotFound`, auth/server errors |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | update receipt (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, auth/server errors |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, auth/server errors |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, auth/server errors |
@@ -470,6 +470,11 @@ end-to-end rollout walkthrough; the CLI mirrors of these methods are
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, auth/server errors |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | decoded workflow output | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` returns the admission receipt, including its `request_id`.
+`query_workflow` and `WorkflowHandle.query` return a query receipt; read
+`receipt["result"]` for the decoded handler value, including when the handler successfully
+returns `None`. See the [Python client guide](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` defaults to `wait_for="accepted"`. Its receipt can have
 `update_status="accepted"` and `result=None`. With `wait_for="completed"`,
 `wait_timeout_seconds` bounds the wait. On expiry, the receipt stays accepted
diff --git a/docs/polyglot/server-config-reference.md b/docs/polyglot/server-config-reference.md
index 3024320bc04..e3c6f5c4f03 100644
--- a/docs/polyglot/server-config-reference.md
+++ b/docs/polyglot/server-config-reference.md
@@ -447,8 +447,8 @@ multiplier from the Server version or summing decoded arguments. Per-value and
 ordinary-route limits remain unchanged. The field grants no additional external
 payload upload or reference-placement authority.
 
-SDK planners must honor a positive advertised cap even below the ordinary
-limit. An absent field preserves the conservative fallback; an explicitly
+Rust SDK 4.16 completion planning honors a positive advertised cap even below
+the ordinary limit. An absent field preserves the conservative fallback; an explicitly
 malformed, null, zero, negative or non-integer value refuses completion planning
 before upload. Ordinary routes ignore this unused completion field.
 
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/python.md
index f60f5dc73b6..693030c3df2 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -412,8 +412,8 @@ Die entsprechenden CLI-Befehle sind `dw task-queue:build-ids`,
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.get_history(workflow_id, run_id)` | decodierte Historiennutzlast | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.export_history(workflow_id, run_id)` | decodierte Archivhistoriennutzlast | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, Authentifizierungs-/Serverfehler |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | decodiertes Abfrageergebnis | `QueryFailed`, `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | Annahmequittung (`dict`) | `WorkflowNotFound`, `InvalidArgument`, Authentifizierungs-/Serverfehler |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | Query-Quittung (`dict`) | `QueryFailed`, `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | Update-Bestätigung (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
@@ -421,6 +421,8 @@ Die entsprechenden CLI-Befehle sind `dw task-queue:build-ids`,
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, Authentifizierungs-/Serverfehler |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | decodierte Workflow-Ausgabe | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` liefert die Annahmequittung einschließlich `request_id`. `query_workflow` und `WorkflowHandle.query` liefern eine Query-Quittung; lesen Sie `receipt["result"]` für den dekodierten Handlerwert, auch wenn der Handler erfolgreich `None` zurückgibt. Siehe den [Python-Client-Leitfaden](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` verwendet standardmäßig `wait_for="accepted"`. Die
 Bestätigung kann `update_status="accepted"` und `result=None` enthalten. Bei
 `wait_for="completed"` begrenzt `wait_timeout_seconds` die Wartezeit. Nach deren
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 0d99e15bb39..3d030fded6b 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -142,7 +142,7 @@ Ein abgeschlossenes null-Ergebnis ist `Ok(Value::Null)`. Ergebnisbestätigungen
 erhalten den expliziten `update_status`. Die Rust-Schnittstelle steht in der
 [Client-API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome).
 
-Rust SDK 4.16 verwendet für die Completion-Planung das explizite Server-Budget `limits.max_workflow_task_completion_bytes`. Ältere Producer ohne dieses Feld behalten die konservative gewöhnliche Grenze. Siehe [Completion-Planung](./server-config-reference.md#rust-completion-planning) für das qualifizierte native3.9.1-Paar und die Grenzen der Payload-Platzierung.
+Rust SDK 4.16 verwendet für die Completion-Planung das explizite Server-Budget `limits.max_workflow_task_completion_bytes`. Ältere Producer ohne dieses Feld behalten die konservative gewöhnliche Grenze. Siehe [Completion-Planung](./server-config-reference.md#rust-completion-planning) für das qualifizierte native 3.9.1-Paar und die Grenzen der Payload-Platzierung.
 
 ## Fristen für Bedingungswarteoperationen und Worker-Upgrades {#condition-wait-deadlines}
 
@@ -237,7 +237,7 @@ Client-Ergebnisse umfassen `ok`, `http_error`, `bridge_rejected`, `TransportErro
 
 Eine Clientbeobachtung umfasst interne Transport-/Storage-Admission-Wiederholungen und Antwort-/Payload-Verarbeitung; getrennte Anwendungs-/Worker-Aufrufe bleiben getrennt. Ein verzögerter Iterator beobachtet jede angefragte Seite. Worker-Polls enthalten verwaltete Wiederholungen/Backoff und unterscheiden `task`, `empty`, `backpressure`, `error`. Task-Ergebnisse `completed`, `failed`, `expired` beschreiben die Verarbeitung, nicht den Workflow-Endzustand. Dies sind Prozessbeobachtungen, keine dauerhaften Zählungen, Abrechnungseinheiten oder Schedule-to-start-Latenzen; abrupter Prozessverlust kann die letzte Probe auslassen.
 
-Rust SDK 4.16 ergänzt das siebte Instrument `durable_workflow_worker_task_schedule_to_start_seconds` mit ausschließlich `task_kind`- und `task_queue`-Tags. Es erfasst die vom Server gemessene Zeit zwischen Ausführungsberechtigung und Claim in Sekunden, wenn der Producer `claimed_task_ready_age` veröffentlicht und gültige `ready_age_ms` liefert. Fehlende, ungültige oder nicht unterstützte Daten erzeugen keinen Messwert; das SDK erfindet keine Null. Die [Kontrollen mit veröffentlichtem4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifizieren alle sieben Metriken, Workflow-/Activity-Ready-Age und den Prometheus-Adapter.
+Rust SDK 4.16 ergänzt das siebte Instrument `durable_workflow_worker_task_schedule_to_start_seconds` mit ausschließlich `task_kind`- und `task_queue`-Tags. Es erfasst die vom Server gemessene Zeit zwischen Ausführungsberechtigung und Claim in Sekunden, wenn der Producer `claimed_task_ready_age` veröffentlicht und gültige `ready_age_ms` liefert. Fehlende, ungültige oder nicht unterstützte Daten erzeugen keinen Messwert; das SDK erfindet keine Null. Die [Kontrollen mit veröffentlichtem 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifizieren alle sieben Metriken, Workflow-/Activity-Ready-Age und den Prometheus-Adapter.
 
 Für den offiziellen Prometheus-Adapter aktivieren Sie das optionale Cargo-Feature `metrics-prometheus`. Das Beispiel nutzt die veröffentlichten Abhängigkeiten:
 
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index c819b450d0d..5789d46c1af 100644
--- a/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -353,13 +353,13 @@ Auf nativem Server 3.6.0 und neuer darf eine Anfrage, die einen Workflow-Task mi
 
 Native 3.9.1 veröffentlicht das tatsächliche Budget als `limits.max_workflow_task_completion_bytes` in Cluster-Info. Es misst für beide Completion-Routen den vollständig kodierten JSON-Anfragekörper einschließlich Envelopes, Metadaten und Befehlen. Verwenden Sie diesen Wert, statt einen Multiplikator aus der Server-Version abzuleiten oder dekodierte Argumentgrößen zu addieren. Die Grenzen pro Wert und für gewöhnliche Routen bleiben unverändert. Das Feld erteilt keine zusätzliche Berechtigung zum Hochladen externer Payloads oder Platzieren von Referenzen.
 
-SDK-Planer müssen eine positive veröffentlichte Grenze auch unterhalb der gewöhnlichen Grenze beachten. Fehlt das Feld, bleibt der konservative Fallback erhalten. Ein explizit fehlerhafter Wert, ein Nullwert (null), die Zahl Null, ein negativer oder nicht ganzzahliger Wert verweigert die Completion-Planung vor dem Upload. Gewöhnliche Routen ignorieren dieses ungenutzte Completion-Feld.
+Der Completion-Planer von Rust SDK 4.16 beachtet eine positive veröffentlichte Grenze auch unterhalb der gewöhnlichen Grenze. Fehlt das Feld, bleibt der konservative Fallback erhalten. Ein explizit fehlerhafter Wert, ein Nullwert (null), die Zahl Null, ein negativer oder nicht ganzzahliger Wert verweigert die Completion-Planung vor dem Upload. Gewöhnliche Routen ignorieren dieses ungenutzte Completion-Feld.
 
 Ein größerer Abschluss wird mit `413 payload_too_large` und `limit_kind: workflow_task_completion_bytes` abgelehnt, bevor etwas aufgezeichnet wird. Eine erneute Ausführung des Tasks erzeugt dieselben Befehle, daher führt erneutes Senden zur selben Ablehnung. Erhält PHP SDK 3.17.0 oder neuer diese typisierte Ablehnung, sendet es die Completion nicht erneut: Der Worker lässt den Lauf einmal mit einem `fail_workflow`-Befehl fehlschlagen, dessen Nachricht mit `Structural limit exceeded: workflow_task_completion_bytes:` beginnt und beide Größen nennt, und der Server zeichnet den Fehler mit `failure_category = structural_limit` auf.
 
 Python SDK 2.17 und Rust SDK 4.15 behandeln die typisierte Ablehnung. Auf Server 3.8.0 traf ein veröffentlichter Python-Kontrolllauf vor HTTP 413 auf `httpx.ReadError` und ließ den Workflow offen. Native 3.9.1 korrigiert diesen Antwortpfad durch begrenztes Verwerfen der Anfrage: höchstens 64 MiB verbleibende Upload-Daten und höchstens zwei Sekunden, bevor die ursprüngliche Ablehnung zurückgegeben und die Verbindung geschlossen wird. Außerhalb dieser Grenzen können weiterhin Transportfehler auftreten.
 
-Das veröffentlichte Python SDK 2.17.1 mit qualifiziertem nativem Server 3.9.1 (linux/amd64, SQLite) besteht nun die [Kontrollen mit tatsächlich installiertem Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): Fan-out von 300 × 10 KB innerhalb der Grenze, genau ein typisiertes 413 und ein struktureller Fehler ohne teilweise gestartete Aktivitäten bei übergroßer Completion, danach eine erfolgreiche Aufgabe auf demselben Worker. Dies qualifiziert genau dieses Python/Server-Paar. PHP benötigt einen eigenen installierten Akzeptanznachweis; Rust4.16 ist unten qualifiziert. Das gemeinsame #228 bleibt offen. Die Request-Key-Akzeptanz unter dem gemeinsamen #216 ist separat.
+Das veröffentlichte Python SDK 2.17.1 mit qualifiziertem nativem Server 3.9.1 (linux/amd64, SQLite) besteht nun die [Kontrollen mit tatsächlich installiertem Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): Fan-out von 300 × 10 KB innerhalb der Grenze, genau ein typisiertes 413 und ein struktureller Fehler ohne teilweise gestartete Aktivitäten bei übergroßer Completion, danach eine erfolgreiche Aufgabe auf demselben Worker. Dies qualifiziert genau dieses Python/Server-Paar. PHP benötigt einen eigenen installierten Akzeptanznachweis; Rust 4.16 ist unten qualifiziert. Das gemeinsame #228 bleibt offen. Die Request-Key-Akzeptanz unter dem gemeinsamen #216 ist separat.
 
 So bleibt ein Abschluss innerhalb der Grenze:
 
@@ -369,7 +369,7 @@ So bleibt ein Abschluss innerhalb der Grenze:
 
 #### Rust-Befehlsplanung {#rust-completion-planning}
 
-Rust SDK 4.16 verwendet das positive explizite Completion-Budget des Producers. Die [Kontrollen mit veröffentlichtem4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) bestehen einen Inline-Fan-out von 300 × 10 KB ohne externen Speicher, einen strukturell fehlschlagenden übergroßen Batch von 60 × 450 KB ohne teilweise gestartete Aktivitäten und eine erfolgreiche Folgeaufgabe auf demselben Worker. Fehlt das explizite Feld, behalten ältere Producer die konservative gewöhnliche Grenze. Das größere Budget gewährt keine neue Upload- oder Referenzplatzierungsberechtigung; Argumente von Activity-Continuation-Befehlen bleiben inline. Diese Kontrollen qualifizieren weder Request-Key-Retries unter dem gemeinsamen #216 noch natives Timeout-Cleanup.
+Rust SDK 4.16 verwendet das positive explizite Completion-Budget des Producers. Die [Kontrollen mit veröffentlichtem 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) bestehen einen Inline-Fan-out von 300 × 10 KB ohne externen Speicher, einen strukturell fehlschlagenden übergroßen Batch von 60 × 450 KB ohne teilweise gestartete Aktivitäten und eine erfolgreiche Folgeaufgabe auf demselben Worker. Fehlt das explizite Feld, behalten ältere Producer die konservative gewöhnliche Grenze. Das größere Budget gewährt keine neue Upload- oder Referenzplatzierungsberechtigung; Argumente von Activity-Continuation-Befehlen bleiben inline. Diese Kontrollen qualifizieren weder Request-Key-Retries unter dem gemeinsamen #216 noch natives Timeout-Cleanup.
 
 ## Docker-Initialisierung und Herkunft {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/de/source-hashes.json b/i18n/de/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/de/source-hashes.json
+++ b/i18n/de/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/python.md
index ba28bc95aa0..d80b519c39c 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -411,8 +411,8 @@ Los equivalentes CLI son `dw task-queue:build-ids`, `dw task-queue:drain` y
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.get_history(workflow_id, run_id)` | carga de historial decodificada | `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.export_history(workflow_id, run_id)` | carga de historial para archivo decodificada | `WorkflowNotFound`, errores de autenticación/servidor |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, errores de autenticación/servidor |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | resultado de consulta decodificado | `QueryFailed`, `WorkflowNotFound`, errores de autenticación/servidor |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | recibo de admisión (`dict`) | `WorkflowNotFound`, `InvalidArgument`, errores de autenticación/servidor |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | recibo de consulta (`dict`) | `QueryFailed`, `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | recibo de actualización (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, errores de autenticación/servidor |
@@ -420,6 +420,8 @@ Los equivalentes CLI son `dw task-queue:build-ids`, `dw task-queue:drain` y
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, errores de autenticación/servidor |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | salida de workflow decodificada | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` devuelve el recibo de admisión, incluido `request_id`. `query_workflow` y `WorkflowHandle.query` devuelven un recibo de consulta; lea `receipt["result"]` para el valor decodificado del handler, incluso cuando devuelve `None` correctamente. Véase la [guía del cliente Python](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` usa `wait_for="accepted"` de forma predeterminada. Su recibo
 puede contener `update_status="accepted"` y `result=None`. Con
 `wait_for="completed"`, `wait_timeout_seconds` limita la espera. Al vencer,
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
index a268ddfe4e9..aaeb2a6587f 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -90,7 +90,7 @@ si la actualización no ha terminado. Un resultado null completado es
 la [API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 para conocer la interfaz de Rust.
 
-Rust SDK 4.16 usa el presupuesto explícito del Server `limits.max_workflow_task_completion_bytes` para planificar finalizaciones. Los productores antiguos sin ese campo conservan el límite ordinario conservador. Consulte [planificación de finalizaciones](./server-config-reference.md#rust-completion-planning) para el par cualificado con native3.9.1 y los límites de ubicación de payloads.
+Rust SDK 4.16 usa el presupuesto explícito del Server `limits.max_workflow_task_completion_bytes` para planificar finalizaciones. Los productores antiguos sin ese campo conservan el límite ordinario conservador. Consulte [planificación de finalizaciones](./server-config-reference.md#rust-completion-planning) para el par cualificado con native 3.9.1 y los límites de ubicación de payloads.
 
 ## Plazos de espera de condiciones y actualización de workers {#condition-wait-deadlines}
 
@@ -185,7 +185,7 @@ Los resultados del cliente incluyen `ok`, `http_error`, `bridge_rejected`, `Tran
 
 Una observación del cliente incluye reintentos internos de transporte/storage admission y manejo de respuesta/payload; llamadas separadas de aplicación/worker se observan por separado. El iterador perezoso observa cada página solicitada. Los polls incluyen retry/backoff gestionados y distinguen `task`, `empty`, `backpressure`, `error`. Los resultados de tarea `completed`, `failed`, `expired` describen el despacho, no el estado terminal del workflow. Son observaciones del proceso, no contadores duraderos, unidades facturables ni latencia schedule-to-start; la pérdida abrupta del proceso puede omitir la muestra final.
 
-Rust SDK 4.16 añade el séptimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, solo con las etiquetas `task_kind` y `task_queue`. Registra en segundos el retraso entre elegibilidad y claim medido por el Server cuando el productor anuncia `claimed_task_ready_age` y suministra `ready_age_ms` válido. Los datos ausentes, inválidos o no admitidos no generan muestra; el SDK nunca inventa un cero. Los [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) cualifican las siete métricas, ready-age de workflows/actividades y el adaptador Prometheus.
+Rust SDK 4.16 añade el séptimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, solo con las etiquetas `task_kind` y `task_queue`. Registra en segundos el retraso entre elegibilidad y claim medido por el Server cuando el productor anuncia `claimed_task_ready_age` y suministra `ready_age_ms` válido. Los datos ausentes, inválidos o no admitidos no generan muestra; el SDK nunca inventa un cero. Los [controles publicados 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) cualifican las siete métricas, ready-age de workflows/actividades y el adaptador Prometheus.
 
 Para el adaptador oficial de Prometheus, active el feature opcional Cargo `metrics-prometheus`. El ejemplo usa la receta publicada de dependencias:
 
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 8659e9b8b49..72a1f574959 100644
--- a/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -342,13 +342,13 @@ En el Server nativo 3.6.0 y posteriores, una solicitud que finaliza una tarea de
 
 El runtime nativo 3.9.1 publica el presupuesto real como `limits.max_workflow_task_completion_bytes` en cluster info. Mide el cuerpo JSON codificado completo de la solicitud, incluidos envelopes, metadatos y comandos, para ambas rutas de finalización. Use ese valor en vez de inferir un multiplicador a partir de la versión o sumar argumentos decodificados. Los límites por valor y de rutas ordinarias no cambian. El campo no concede permisos adicionales de subida de payloads externos ni de colocación de referencias.
 
-Los planificadores de los SDK deben respetar un límite positivo publicado incluso si es menor que el ordinario. Si el campo falta, se conserva el fallback conservador; un valor explícitamente mal formado, nulo, cero, negativo o no entero rechaza la planificación antes de subir datos. Las rutas ordinarias ignoran este campo de finalización no utilizado.
+El planificador de finalizaciones de Rust SDK 4.16 respeta un límite positivo publicado incluso si es menor que el ordinario. Si el campo falta, se conserva el fallback conservador; un valor explícitamente mal formado, nulo, cero, negativo o no entero rechaza la planificación antes de subir datos. Las rutas ordinarias ignoran este campo de finalización no utilizado.
 
 Una finalización mayor se rechaza con `413 payload_too_large` y `limit_kind: workflow_task_completion_bytes` antes de registrar nada. Reproducir la tarea genera los mismos comandos, así que reenviar la finalización recibe el mismo rechazo. Cuando PHP SDK 3.17.0 o posterior recibe este rechazo tipado, no reenvía la finalización: el worker hace fallar la ejecución una sola vez con un comando `fail_workflow` cuyo mensaje empieza por `Structural limit exceeded: workflow_task_completion_bytes:` e indica ambos tamaños, y el Server registra el fallo con `failure_category = structural_limit`.
 
 Python SDK 2.17 y Rust SDK 4.15 incluyen el manejo del rechazo tipado. En Server 3.8.0, un control publicado de Python obtuvo `httpx.ReadError` antes de recibir HTTP 413 y dejó el workflow pendiente. El runtime nativo 3.9.1 corrige esa respuesta descartando datos de forma acotada: como máximo 64 MiB de la subida restante durante dos segundos, antes de devolver el rechazo original y cerrar la conexión. Las subidas que superen cualquiera de esos límites aún pueden sufrir errores de transporte.
 
-Python SDK 2.17.1 publicado con Server nativo 3.9.1 cualificado (linux/amd64, SQLite) supera ahora los [controles con el Worker instalado real](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro del límite, un único 413 tipado y un único fallo estructural sin actividades parciales para una finalización sobredimensionada, y después una tarea correcta en el mismo Worker. Esto cualifica ese par exacto Python/Server. PHP requiere su propia aceptación instalada; Rust4.16 se cualifica abajo. El #228 compartido sigue abierto. La aceptación de claves de solicitud del #216 compartido es independiente.
+Python SDK 2.17.1 publicado con Server nativo 3.9.1 cualificado (linux/amd64, SQLite) supera ahora los [controles con el Worker instalado real](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro del límite, un único 413 tipado y un único fallo estructural sin actividades parciales para una finalización sobredimensionada, y después una tarea correcta en el mismo Worker. Esto cualifica ese par exacto Python/Server. PHP requiere su propia aceptación instalada; Rust 4.16 se cualifica abajo. El #228 compartido sigue abierto. La aceptación de claves de solicitud del #216 compartido es independiente.
 
 Para mantener una finalización dentro del límite:
 
@@ -358,7 +358,7 @@ Para mantener una finalización dentro del límite:
 
 #### Planificación de comandos en Rust {#rust-completion-planning}
 
-Rust SDK 4.16 usa el presupuesto positivo explícito de finalización anunciado por el productor. Los [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) superan fan-out inline de 300 × 10 KB sin almacenamiento externo, un lote sobredimensionado de 60 × 450 KB que falla estructuralmente sin actividades parciales y una tarea posterior correcta en el mismo Worker. Sin el campo explícito, los productores antiguos conservan el límite ordinario conservador. El presupuesto mayor no concede nuevos permisos de subida o colocación de referencias; los argumentos de comandos de continuación de actividades siguen inline. Estos controles no cualifican los reintentos con clave del #216 compartido ni la limpieza por timeout nativa.
+Rust SDK 4.16 usa el presupuesto positivo explícito de finalización anunciado por el productor. Los [controles publicados 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) superan fan-out inline de 300 × 10 KB sin almacenamiento externo, un lote sobredimensionado de 60 × 450 KB que falla estructuralmente sin actividades parciales y una tarea posterior correcta en el mismo Worker. Sin el campo explícito, los productores antiguos conservan el límite ordinario conservador. El presupuesto mayor no concede nuevos permisos de subida o colocación de referencias; los argumentos de comandos de continuación de actividades siguen inline. Estos controles no cualifican los reintentos con clave del #216 compartido ni la limpieza por timeout nativa.
 
 ## Inicialización de Docker y procedencia {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/es/source-hashes.json b/i18n/es/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/es/source-hashes.json
+++ b/i18n/es/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/python.md
index 9cad8311bb8..42fe7af9448 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -417,8 +417,8 @@ parcours complet. Les équivalents CLI sont `dw task-queue:build-ids`,
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.get_history(workflow_id, run_id)` | charge utile d'historique décodée | `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.export_history(workflow_id, run_id)` | historique d'archivage décodé | `WorkflowNotFound`, erreurs d'authentification/serveur |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, erreurs d'authentification/serveur |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | résultat de requête décodé | `QueryFailed`, `WorkflowNotFound`, erreurs d'authentification/serveur |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | reçu d’admission (`dict`) | `WorkflowNotFound`, `InvalidArgument`, erreurs d'authentification/serveur |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | reçu de requête (`dict`) | `QueryFailed`, `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | accusé de mise à jour (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, erreurs d'authentification/serveur |
@@ -426,6 +426,8 @@ parcours complet. Les équivalents CLI sont `dw task-queue:build-ids`,
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, erreurs d'authentification/serveur |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | sortie de workflow décodée | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` renvoie le reçu d’admission avec son `request_id`. `query_workflow` et `WorkflowHandle.query` renvoient un reçu de requête ; lisez `receipt["result"]` pour la valeur décodée du handler, y compris lorsque celui-ci renvoie `None` avec succès. Voir le [guide du client Python](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` utilise `wait_for="accepted"` par défaut. Son accusé peut
 contenir `update_status="accepted"` et `result=None`. Avec
 `wait_for="completed"`, `wait_timeout_seconds` borne l'attente. À son expiration,
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
index ca55c001473..4868d6c46d2 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -147,7 +147,7 @@ inachevée. Un résultat null terminé est `Ok(Value::Null)`. Les accusés conse
 le `update_status` explicite. Consultez l'[API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 pour l'interface Rust.
 
-Rust SDK 4.16 utilise le budget explicite du Server `limits.max_workflow_task_completion_bytes` pour planifier les finalisations. Les anciens producteurs sans ce champ conservent le plafond ordinaire conservateur. Consultez la [planification des finalisations](./server-config-reference.md#rust-completion-planning) pour le couple qualifié avec native3.9.1 et les limites de placement des payloads.
+Rust SDK 4.16 utilise le budget explicite du Server `limits.max_workflow_task_completion_bytes` pour planifier les finalisations. Les anciens producteurs sans ce champ conservent le plafond ordinaire conservateur. Consultez la [planification des finalisations](./server-config-reference.md#rust-completion-planning) pour le couple qualifié avec native 3.9.1 et les limites de placement des payloads.
 
 ## Échéances des attentes de condition et mise à niveau des workers {#condition-wait-deadlines}
 
@@ -243,7 +243,7 @@ Les résultats client incluent `ok`, `http_error`, `bridge_rejected`, `Transport
 
 Une observation client inclut les réessais internes de transport/storage admission et le traitement réponse/payload ; les appels distincts gérés par l’application/worker sont séparés. L’itérateur paresseux observe chaque page chargée. Les polls incluent retry/backoff gérés et distinguent `task`, `empty`, `backpressure`, `error`. Les résultats task `completed`, `failed`, `expired` décrivent le traitement, pas l’état terminal du workflow. Ce sont des observations de processus, pas des comptes durables, unités facturables ou latences schedule-to-start ; une perte brutale peut omettre l’échantillon final.
 
-Rust SDK 4.16 ajoute le septième instrument, `durable_workflow_worker_task_schedule_to_start_seconds`, avec les seules étiquettes `task_kind` et `task_queue`. Il enregistre en secondes le délai entre éligibilité et claim mesuré par le Server lorsque le producteur annonce `claimed_task_ready_age` et fournit un `ready_age_ms` valide. Une donnée absente, invalide ou non prise en charge ne produit aucun échantillon ; le SDK n’invente jamais un zéro. Les [contrôles publiés4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifient les sept métriques, le ready-age workflow/activité et l’adaptateur Prometheus.
+Rust SDK 4.16 ajoute le septième instrument, `durable_workflow_worker_task_schedule_to_start_seconds`, avec les seules étiquettes `task_kind` et `task_queue`. Il enregistre en secondes le délai entre éligibilité et claim mesuré par le Server lorsque le producteur annonce `claimed_task_ready_age` et fournit un `ready_age_ms` valide. Une donnée absente, invalide ou non prise en charge ne produit aucun échantillon ; le SDK n’invente jamais un zéro. Les [contrôles publiés 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualifient les sept métriques, le ready-age workflow/activité et l’adaptateur Prometheus.
 
 Pour l’adaptateur officiel Prometheus, activez le feature Cargo facultatif `metrics-prometheus`. Cet exemple utilise les dépendances publiées :
 
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index bfd25af2521..80b29382cb4 100644
--- a/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -342,13 +342,13 @@ Sur Server natif 3.6.0 et ultérieur, une requête qui achève une tâche de wor
 
 Le runtime natif 3.9.1 publie le budget réel dans `limits.max_workflow_task_completion_bytes` via cluster info. Il mesure le corps JSON encodé complet, avec les enveloppes, métadonnées et commandes, pour les deux routes de finalisation. Utilisez cette valeur au lieu de déduire un multiplicateur de la version ou d’additionner les arguments décodés. Les limites par valeur et des routes ordinaires restent inchangées. Ce champ n’accorde aucune autorisation supplémentaire de téléversement de payloads externes ou de placement de références.
 
-Les planificateurs des SDK doivent respecter un plafond positif publié même inférieur à la limite ordinaire. L’absence du champ conserve le repli conservateur ; une valeur explicite mal formée, nulle, zéro, négative ou non entière refuse la planification avant le téléversement. Les routes ordinaires ignorent ce champ de finalisation inutilisé.
+Le planificateur de finalisations de Rust SDK 4.16 respecte un plafond positif publié même inférieur à la limite ordinaire. L’absence du champ conserve le repli conservateur ; une valeur explicite mal formée, nulle, zéro, négative ou non entière refuse la planification avant le téléversement. Les routes ordinaires ignorent ce champ de finalisation inutilisé.
 
 Un achèvement plus grand est refusé avec `413 payload_too_large` et `limit_kind: workflow_task_completion_bytes` avant tout enregistrement. Rejouer la tâche produit les mêmes commandes : renvoyer l’achèvement obtient donc le même refus. Lorsque PHP SDK 3.17.0 ou ultérieur reçoit ce refus typé, il ne renvoie pas cet achèvement : le worker fait échouer l’exécution une seule fois avec une commande `fail_workflow` dont le message commence par `Structural limit exceeded: workflow_task_completion_bytes:` et indique les deux tailles, et le Server enregistre l’échec avec `failure_category = structural_limit`.
 
 Python SDK 2.17 et Rust SDK 4.15 gèrent le refus typé. Sur Server 3.8.0, un contrôle Python publié rencontrait `httpx.ReadError` avant HTTP 413 et laissait le workflow en attente. Le runtime natif 3.9.1 corrige cette réponse par une lecture puis un abandon bornés du reste de la requête : au plus 64 MiB pendant deux secondes avant de renvoyer le refus original et fermer la connexion. Au-delà de l’une de ces bornes, des erreurs de transport restent possibles.
 
-Le SDK Python 2.17.1 publié avec le Server natif 3.9.1 qualifié (linux/amd64, SQLite) réussit désormais les [contrôles sur le Worker réellement installé](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512) : fan-out de 300 × 10 KB dans la limite, un seul 413 typé et un seul échec structurel sans activité partielle pour une finalisation trop grande, puis une tâche réussie sur le même Worker. Cela qualifie ce couple exact Python/Server. PHP nécessite sa propre preuve sur installation ; Rust4.16 est qualifié ci-dessous. Le #228 partagé reste ouvert. L’acceptation des clés de requête du #216 partagé est distincte.
+Le SDK Python 2.17.1 publié avec le Server natif 3.9.1 qualifié (linux/amd64, SQLite) réussit désormais les [contrôles sur le Worker réellement installé](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512) : fan-out de 300 × 10 KB dans la limite, un seul 413 typé et un seul échec structurel sans activité partielle pour une finalisation trop grande, puis une tâche réussie sur le même Worker. Cela qualifie ce couple exact Python/Server. PHP nécessite sa propre preuve sur installation ; Rust 4.16 est qualifié ci-dessous. Le #228 partagé reste ouvert. L’acceptation des clés de requête du #216 partagé est distincte.
 
 Pour garder un achèvement sous la limite :
 
@@ -358,7 +358,7 @@ Pour garder un achèvement sous la limite :
 
 #### Planification des commandes Rust {#rust-completion-planning}
 
-Rust SDK 4.16 utilise le budget de finalisation positif et explicite annoncé par le producteur. Les [contrôles publiés4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) réussissent un fan-out inline de 300 × 10 KB sans stockage externe, un lot trop grand de 60 × 450 KB échouant structurellement sans activité partielle, puis une tâche réussie sur le même Worker. Sans le champ explicite, les anciens producteurs gardent le plafond ordinaire conservateur. Le budget supérieur n’accorde aucun droit supplémentaire de téléversement ou placement de références ; les arguments des commandes de continuation d’activité restent inline. Ces contrôles ne qualifient ni les reprises avec clé du #216 partagé ni le nettoyage natif après timeout.
+Rust SDK 4.16 utilise le budget de finalisation positif et explicite annoncé par le producteur. Les [contrôles publiés 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) réussissent un fan-out inline de 300 × 10 KB sans stockage externe, un lot trop grand de 60 × 450 KB échouant structurellement sans activité partielle, puis une tâche réussie sur le même Worker. Sans le champ explicite, les anciens producteurs gardent le plafond ordinaire conservateur. Le budget supérieur n’accorde aucun droit supplémentaire de téléversement ou placement de références ; les arguments des commandes de continuation d’activité restent inline. Ces contrôles ne qualifient ni les reprises avec clé du #216 partagé ni le nettoyage natif après timeout.
 
 ## Initialisation Docker et provenance {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/fr/source-hashes.json b/i18n/fr/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/fr/source-hashes.json
+++ b/i18n/fr/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/python.md
index 19a5d4ab366..e988a942cdb 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -343,8 +343,8 @@ driver = external_storage_driver_from_policy(
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`、認証・Server エラー |
 | `await client.get_history(workflow_id, run_id)` | デコード済み履歴ペイロード | `WorkflowNotFound`、認証・Server エラー |
 | `await client.export_history(workflow_id, run_id)` | デコード済みアーカイブ履歴ペイロード | `WorkflowNotFound`、認証・Server エラー |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`、`InvalidArgument`、認証・Server エラー |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | デコード済みクエリ結果 | `QueryFailed`、`WorkflowNotFound`、認証・Server エラー |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | 受け付けレシート (`dict`) | `WorkflowNotFound`、`InvalidArgument`、認証・Server エラー |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | クエリレシート (`dict`) | `QueryFailed`、`WorkflowNotFound`、認証・Server エラー |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | 更新レシート（`dict`） | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`、`WorkflowNotFound`、認証・Server エラー |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`、認証・Server エラー |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`、認証・Server エラー |
@@ -352,6 +352,8 @@ driver = external_storage_driver_from_policy(
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`、認証・Server エラー |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | デコード済みワークフロー出力 | `WorkflowFailed`、`WorkflowCancelled`、`WorkflowTerminated`、`TimeoutError` |
 
+`signal_workflow` は `request_id` を含む受け付けレシートを返します。`query_workflow` と `WorkflowHandle.query` はクエリレシートを返すため、ハンドラーが正常に `None` を返す場合も、デコード済みの値は `receipt["result"]` から取得してください。[Python クライアントガイド](https://python.durable-workflow.com/reference/client/)を参照してください。
+
 `update_workflow` の既定は `wait_for="accepted"` です。レシートは `update_status="accepted"` と `result=None` を含む場合があります。`wait_for="completed"` では、`wait_timeout_seconds` が待機時間を制限します。期限が切れると、レシートは受け付け済みのまま `wait_timed_out=True` を設定します。`None` を含む完了した結果は、`update_status="completed"` でのみ識別できます。`update_id` を保持し、[後から結果を読み取ってください](https://python.durable-workflow.com/reference/client/#read-an-update-outcome)。
 
 `start_workflow` は `workflow_type`、`task_queue`、任意の `workflow_id`、`input`、`duplicate_policy`、`memo`、`search_attributes`、`business_key`、`execution_timeout_seconds`、`run_timeout_seconds` を受け入れます。呼び出し元のすべてのペイロードは HTTP 境界を越える前に Avro エンベロープ化します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
index dfd6e9ced6a..a73fd487283 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -83,7 +83,7 @@ Server はメジャー `1` 内で Worker プロトコルヘッダーをネゴシ
 
 Rust SDK 4.15 では、受け付け済みの更新を ID で読み取り、再送信を避ける `Client::update_outcome` と `Client::update_outcome_receipt` が追加されました。これらには `capabilities.update_outcome_reads`（native Server 3.6.0 以降）が必要です。`update_outcome` は未完了の更新に対して `Error::UpdateStillPending` を返します。完了した null の結果は `Ok(Value::Null)` です。レシートは明示的な `update_status` を保持します。Rust のインターフェースは [Client API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome) を参照してください。
 
-Rust SDK 4.16 は Server が明示する `limits.max_workflow_task_completion_bytes` 予算を完了計画に使います。このフィールドがない古い producer では、保守的な通常の上限を維持します。検証済み native3.9.1 との組み合わせと payload 配置の制限は[完了計画](./server-config-reference.md#rust-completion-planning)を参照してください。
+Rust SDK 4.16 は Server が明示する `limits.max_workflow_task_completion_bytes` 予算を完了計画に使います。このフィールドがない古い producer では、保守的な通常の上限を維持します。検証済み native 3.9.1 との組み合わせと payload 配置の制限は[完了計画](./server-config-reference.md#rust-completion-planning)を参照してください。
 
 ## 条件待機の期限と Worker のアップグレード {#condition-wait-deadlines}
 
@@ -175,7 +175,7 @@ Ok(())
 
 クライアントの1観測には内部 transport/storage admission の再試行と応答/payload 処理を含み、アプリや worker が管理する別呼び出しは別観測です。遅延イテレーターは取得ページごとに観測します。worker poll は管理された retry/backoff を含み、`task`、`empty`、`backpressure`、`error` を区別します。task 結果の `completed`、`failed`、`expired` は処理結果であり workflow の終端状態ではありません。これはプロセス観測で、永続カウント、課金単位、schedule-to-start 遅延ではなく、突然のプロセス喪失で最後のサンプルが失われる場合があります。
 
-Rust SDK 4.16 は 7 番目の計測器 `durable_workflow_worker_task_schedule_to_start_seconds` を追加し、タグは `task_kind` と `task_queue` のみです。producer が `claimed_task_ready_age` を広告し、有効な `ready_age_ms` を返す場合に、Server が計測した実行可能時点から claim までの遅延を秒単位で記録します。データの欠落、不正、非対応時にはサンプルを出さず、ゼロを捏造しません。[公開済み4.16/native3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、7 メトリクスすべて、workflow/Activity の ready-age、Prometheus アダプターを確認しています。
+Rust SDK 4.16 は 7 番目の計測器 `durable_workflow_worker_task_schedule_to_start_seconds` を追加し、タグは `task_kind` と `task_queue` のみです。producer が `claimed_task_ready_age` を広告し、有効な `ready_age_ms` を返す場合に、Server が計測した実行可能時点から claim までの遅延を秒単位で記録します。データの欠落、不正、非対応時にはサンプルを出さず、ゼロを捏造しません。[公開済み 4.16/native 3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、7 メトリクスすべて、workflow/Activity の ready-age、Prometheus アダプターを確認しています。
 
 公式 Prometheus adapter には任意の Cargo feature `metrics-prometheus` を有効にします。この例は公開済みの依存関係設定を使います。
 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index db0d2e9505f..acde7d099fe 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -328,13 +328,13 @@ native Server 3.6.0 以降では、コマンド付きでワークフロータス
 
 native 3.9.1 は cluster info の `limits.max_workflow_task_completion_bytes` に実際の予算を公開します。両方の完了ルートについて、エンベロープ、メタデータ、コマンドを含む、エンコード済み JSON リクエスト本文全体のサイズです。Server のバージョンから倍率を推測したり、デコード済み引数を合計したりせず、この値を使ってください。値ごとと通常ルートの上限は変わりません。このフィールドは、外部 payload のアップロードや参照配置の追加権限を与えません。
 
-SDK のプランナーは、通常の上限より小さくても、公開された正の上限を守る必要があります。フィールドがなければ保守的なフォールバックを維持します。明示的な不正値、null、ゼロ、負数、非整数の場合はアップロード前に完了計画を拒否します。通常ルートは、この未使用の完了フィールドを無視します。
+Rust SDK 4.16 の完了プランナーは、通常の上限より小さくても、公開された正の上限を守ります。フィールドがなければ保守的なフォールバックを維持します。明示的な不正値、null、ゼロ、負数、非整数の場合はアップロード前に完了計画を拒否します。通常ルートは、この未使用の完了フィールドを無視します。
 
 それより大きい完了は、何も記録される前に `413 payload_too_large` と `limit_kind: workflow_task_completion_bytes` で拒否されます。タスクをリプレイしても同じコマンドが生成されるため、完了を再送しても同じ拒否になります。PHP SDK 3.17.0 以降は、この型付き拒否を受信した場合、完了リクエストを再送しません。Worker は `Structural limit exceeded: workflow_task_completion_bytes:` で始まり両方のサイズを示すメッセージの `fail_workflow` コマンドで実行を一度だけ失敗させ、Server はその失敗を `failure_category = structural_limit` として記録します。
 
 Python SDK 2.17 と Rust SDK 4.15 には型付き拒否の処理があります。Server 3.8.0 の公開済み Python 検証では HTTP 413 を受け取る前に `httpx.ReadError` が発生し、workflow が保留されました。native 3.9.1 は、残りのアップロードを最大 64 MiB、最大 2 秒間だけ破棄してから元の拒否を返し、接続を閉じることで応答経路を修正します。どちらかの境界を超えるアップロードでは、引き続きトランスポートエラーが起こり得ます。
 
-公開済み Python SDK 2.17.1 と検証済み native Server 3.9.1（linux/amd64、SQLite）は、[実際にインストールした Worker の検証](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)に合格しました。上限内の 300 × 10 KB fan-out、大きすぎる完了に対する型付き 413 が 1 回と構造的失敗が 1 回、部分的な Activity がゼロ、その後の同じ Worker でのタスク成功を確認しています。この特定の Python/Server 組み合わせの検証です。PHP には独自のインストール済み検証が必要です。Rust4.16 の検証は下記に示します。共有 #228 は未完了です。共有 #216 のリクエストキー検証は別です。
+公開済み Python SDK 2.17.1 と検証済み native Server 3.9.1（linux/amd64、SQLite）は、[実際にインストールした Worker の検証](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)に合格しました。上限内の 300 × 10 KB fan-out、大きすぎる完了に対する型付き 413 が 1 回と構造的失敗が 1 回、部分的な Activity がゼロ、その後の同じ Worker でのタスク成功を確認しています。この特定の Python/Server 組み合わせの検証です。PHP には独自のインストール済み検証が必要です。Rust 4.16 の検証は下記に示します。共有 #228 は未完了です。共有 #216 のリクエストキー検証は別です。
 
 完了を上限内に収めるには：
 
@@ -344,7 +344,7 @@ Python SDK 2.17 と Rust SDK 4.15 には型付き拒否の処理があります
 
 #### Rust のコマンド計画 {#rust-completion-planning}
 
-Rust SDK 4.16 は producer が広告した明示的な正の完了予算を使います。[公開済み4.16/native3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、外部ストレージなしの 300 × 10 KB inline fan-out、部分的な Activity ゼロで構造的に失敗する上限超過の 60 × 450 KB バッチ、その後の同じ Worker でのタスク成功を確認しています。明示的なフィールドがなければ、古い producer は保守的な通常の上限を維持します。予算が増えても、アップロードや参照配置の追加権限は得られず、Activity continuation のコマンド引数は inline のままです。この検証は共有 #216 のキー付き再試行や native のタイムアウト清理を確認するものではありません。
+Rust SDK 4.16 は producer が広告した明示的な正の完了予算を使います。[公開済み 4.16/native 3.9.1 の検証](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）は、外部ストレージなしの 300 × 10 KB inline fan-out、部分的な Activity ゼロで構造的に失敗する上限超過の 60 × 450 KB バッチ、その後の同じ Worker でのタスク成功を確認しています。明示的なフィールドがなければ、古い producer は保守的な通常の上限を維持します。予算が増えても、アップロードや参照配置の追加権限は得られず、Activity continuation のコマンド引数は inline のままです。この検証は共有 #216 のキー付き再試行や native のタイムアウトクリーンアップを確認するものではありません。
 
 ## Docker の初期化と出所情報 {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/ja/source-hashes.json b/i18n/ja/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/ja/source-hashes.json
+++ b/i18n/ja/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/python.md
index 9b303713eef..50d6fde2952 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -416,8 +416,8 @@ o procedimento completo; os equivalentes CLI são `dw task-queue:build-ids`,
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.get_history(workflow_id, run_id)` | payload de histórico decodificado | `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.export_history(workflow_id, run_id)` | payload de histórico de arquivo decodificado | `WorkflowNotFound`, erros de autenticação/servidor |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, erros de autenticação/servidor |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | resultado de consulta decodificado | `QueryFailed`, `WorkflowNotFound`, erros de autenticação/servidor |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | recibo de admissão (`dict`) | `WorkflowNotFound`, `InvalidArgument`, erros de autenticação/servidor |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | recibo de consulta (`dict`) | `QueryFailed`, `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | recibo de atualização (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, erros de autenticação/servidor |
@@ -425,6 +425,8 @@ o procedimento completo; os equivalentes CLI são `dw task-queue:build-ids`,
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, erros de autenticação/servidor |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | saída decodificada do workflow | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` retorna o recibo de admissão, incluindo `request_id`. `query_workflow` e `WorkflowHandle.query` retornam um recibo de consulta; leia `receipt["result"]` para o valor decodificado do handler, inclusive quando retorna `None` com sucesso. Veja o [guia do cliente Python](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` usa `wait_for="accepted"` por padrão. Seu recibo pode conter
 `update_status="accepted"` e `result=None`. Com `wait_for="completed"`,
 `wait_timeout_seconds` limita a espera. Quando ela expira, o recibo continua
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 64a8eb58030..aed47cf4a73 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -141,7 +141,7 @@ resultado null concluído é `Ok(Value::Null)`. Os recibos preservam o
 `update_status` explícito. Veja a [API de Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)
 para a interface de Rust.
 
-Rust SDK 4.16 usa o orçamento explícito do Server `limits.max_workflow_task_completion_bytes` para planejar conclusões. Produtores antigos sem esse campo mantêm o limite comum conservador. Veja o [planejamento de conclusões](./server-config-reference.md#rust-completion-planning) para o par qualificado com native3.9.1 e os limites de posicionamento de payloads.
+Rust SDK 4.16 usa o orçamento explícito do Server `limits.max_workflow_task_completion_bytes` para planejar conclusões. Produtores antigos sem esse campo mantêm o limite comum conservador. Veja o [planejamento de conclusões](./server-config-reference.md#rust-completion-planning) para o par qualificado com native 3.9.1 e os limites de posicionamento de payloads.
 
 ## Prazos de espera de condições e atualização de workers {#condition-wait-deadlines}
 
@@ -235,7 +235,7 @@ Resultados do cliente incluem `ok`, `http_error`, `bridge_rejected`, `TransportE
 
 Uma observação do cliente inclui repetições internas de transporte/storage admission e tratamento de resposta/payload; chamadas separadas da aplicação/worker são observadas separadamente. Um iterador preguiçoso observa cada página buscada. Polls incluem retry/backoff gerenciados e distinguem `task`, `empty`, `backpressure`, `error`. Resultados `completed`, `failed`, `expired` descrevem o despacho, não o estado terminal do workflow. São observações de processo, não contagens duráveis, unidades de cobrança ou latência schedule-to-start; perda abrupta pode omitir a amostra final.
 
-Rust SDK 4.16 adiciona o sétimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, apenas com as tags `task_kind` e `task_queue`. Ele registra em segundos a demora entre elegibilidade e claim medida pelo Server quando o produtor anuncia `claimed_task_ready_age` e fornece `ready_age_ms` válido. Dados ausentes, inválidos ou não suportados não geram amostra; o SDK nunca inventa zero. Os [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualificam as sete métricas, ready-age de workflow/atividade e o adaptador Prometheus.
+Rust SDK 4.16 adiciona o sétimo instrumento, `durable_workflow_worker_task_schedule_to_start_seconds`, apenas com as tags `task_kind` e `task_queue`. Ele registra em segundos a demora entre elegibilidade e claim medida pelo Server quando o produtor anuncia `claimed_task_ready_age` e fornece `ready_age_ms` válido. Dados ausentes, inválidos ou não suportados não geram amostra; o SDK nunca inventa zero. Os [controles publicados 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) qualificam as sete métricas, ready-age de workflow/atividade e o adaptador Prometheus.
 
 Para o adaptador oficial Prometheus, habilite o feature Cargo opcional `metrics-prometheus`. O exemplo usa a receita publicada de dependências:
 
diff --git a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index c99a77a36b1..eb6d92a02d4 100644
--- a/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/pt-BR/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -342,13 +342,13 @@ No Server nativo 3.6.0 e posteriores, uma requisição que conclui uma tarefa de
 
 O runtime nativo 3.9.1 publica o orçamento real em `limits.max_workflow_task_completion_bytes` no cluster info. Ele mede o corpo JSON codificado completo, incluindo envelopes, metadados e comandos, nas duas rotas de conclusão. Use esse valor em vez de inferir um multiplicador pela versão ou somar argumentos decodificados. Os limites por valor e de rotas comuns não mudam. O campo não concede autorização adicional para upload de payloads externos ou posicionamento de referências.
 
-Os planejadores dos SDKs devem respeitar um limite positivo publicado mesmo abaixo do limite comum. Campo ausente mantém o fallback conservador; um valor explícito malformado, nulo, zero, negativo ou não inteiro recusa o planejamento antes do upload. Rotas comuns ignoram esse campo de conclusão não utilizado.
+O planejador de conclusões do Rust SDK 4.16 respeita um limite positivo publicado mesmo abaixo do limite comum. Campo ausente mantém o fallback conservador; um valor explícito malformado, nulo, zero, negativo ou não inteiro recusa o planejamento antes do upload. Rotas comuns ignoram esse campo de conclusão não utilizado.
 
 Uma conclusão maior é recusada com `413 payload_too_large` e `limit_kind: workflow_task_completion_bytes` antes que algo seja registrado. Reexecutar a tarefa produz os mesmos comandos, então reenviar a conclusão recebe a mesma recusa. Quando o PHP SDK 3.17.0 ou posterior recebe essa recusa tipada, não reenvia a conclusão: o worker falha a execução uma única vez com um comando `fail_workflow` cuja mensagem começa com `Structural limit exceeded: workflow_task_completion_bytes:` e informa os dois tamanhos, e o Server registra a falha com `failure_category = structural_limit`.
 
 Python SDK 2.17 e Rust SDK 4.15 incluem tratamento para a recusa tipada. No Server 3.8.0, um controle Python publicado recebeu `httpx.ReadError` antes do HTTP 413 e deixou o workflow pendente. O runtime nativo 3.9.1 corrige a resposta descartando dados de forma limitada: no máximo 64 MiB da carga restante por até dois segundos, antes de devolver a recusa original e fechar a conexão. Uploads que ultrapassem qualquer limite ainda podem ter erros de transporte.
 
-O Python SDK 2.17.1 publicado com o Server nativo 3.9.1 qualificado (linux/amd64, SQLite) agora passa nos [controles com Worker realmente instalado](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro do limite, um único 413 tipado e uma única falha estrutural sem atividades parciais para uma conclusão grande demais, e depois uma tarefa bem-sucedida no mesmo Worker. Isso qualifica esse par exato Python/Server. PHP exige sua própria aceitação instalada; Rust4.16 está qualificado abaixo. O #228 compartilhado continua aberto. A aceitação de chaves de requisição do #216 compartilhado é separada.
+O Python SDK 2.17.1 publicado com o Server nativo 3.9.1 qualificado (linux/amd64, SQLite) agora passa nos [controles com Worker realmente instalado](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out de 300 × 10 KB dentro do limite, um único 413 tipado e uma única falha estrutural sem atividades parciais para uma conclusão grande demais, e depois uma tarefa bem-sucedida no mesmo Worker. Isso qualifica esse par exato Python/Server. PHP exige sua própria aceitação instalada; Rust 4.16 está qualificado abaixo. O #228 compartilhado continua aberto. A aceitação de chaves de requisição do #216 compartilhado é separada.
 
 Para manter uma conclusão dentro do limite:
 
@@ -358,7 +358,7 @@ Para manter uma conclusão dentro do limite:
 
 #### Planejamento de comandos em Rust {#rust-completion-planning}
 
-Rust SDK 4.16 usa o orçamento positivo explícito de conclusão anunciado pelo produtor. Os [controles publicados4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) passam fan-out inline de 300 × 10 KB sem armazenamento externo, um lote grande demais de 60 × 450 KB que falha estruturalmente sem atividades parciais e uma tarefa posterior bem-sucedida no mesmo Worker. Sem o campo explícito, produtores antigos mantêm o limite comum conservador. O orçamento maior não concede nova autorização de upload ou referências; argumentos de comandos de continuação de atividades permanecem inline. Esses controles não qualificam retries com chave do #216 compartilhado nem limpeza nativa por timeout.
+Rust SDK 4.16 usa o orçamento positivo explícito de conclusão anunciado pelo produtor. Os [controles publicados 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) passam fan-out inline de 300 × 10 KB sem armazenamento externo, um lote grande demais de 60 × 450 KB que falha estruturalmente sem atividades parciais e uma tarefa posterior bem-sucedida no mesmo Worker. Sem o campo explícito, produtores antigos mantêm o limite comum conservador. O orçamento maior não concede nova autorização de upload ou referências; argumentos de comandos de continuação de atividades permanecem inline. Esses controles não qualificam retries com chave do #216 compartilhado nem limpeza nativa por timeout.
 
 ## Inicialização do Docker e procedência {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/pt-BR/source-hashes.json b/i18n/pt-BR/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/pt-BR/source-hashes.json
+++ b/i18n/pt-BR/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/python.md
index c744e03cdaa..8a3722a174d 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -410,8 +410,8 @@ Namespace є межею орендарів workflow, schedule, атрибуті
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.get_history(workflow_id, run_id)` | декодований payload історії | `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.export_history(workflow_id, run_id)` | декодований архівний payload історії | `WorkflowNotFound`, помилки автентифікації/Server |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, помилки автентифікації/Server |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | декодований результат query | `QueryFailed`, `WorkflowNotFound`, помилки автентифікації/Server |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | квитанція прийняття (`dict`) | `WorkflowNotFound`, `InvalidArgument`, помилки автентифікації/Server |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | квитанція запиту (`dict`) | `QueryFailed`, `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | підтвердження update (`dict`) | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, помилки автентифікації/Server |
@@ -419,6 +419,8 @@ Namespace є межею орендарів workflow, schedule, атрибуті
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, помилки автентифікації/Server |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | декодований результат workflow | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` повертає квитанцію прийняття разом із `request_id`. `query_workflow` і `WorkflowHandle.query` повертають квитанцію запиту; читайте `receipt["result"]` для декодованого значення обробника, навіть коли він успішно повертає `None`. Дивіться [посібник клієнта Python](https://python.durable-workflow.com/reference/client/).
+
 `update_workflow` за замовчуванням використовує `wait_for="accepted"`.
 Підтвердження може містити `update_status="accepted"` і `result=None`. З
 `wait_for="completed"` параметр `wait_timeout_seconds` обмежує час очікування.
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 4884b186046..f4086570efa 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -141,7 +141,7 @@ Rust SDK 4.15 додає `Client::update_outcome` і
 null має вигляд `Ok(Value::Null)`. Підтвердження зберігають явний `update_status`.
 Інтерфейс Rust описано в [API Client](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome).
 
-Rust SDK 4.16 використовує явний бюджет Server `limits.max_workflow_task_completion_bytes` для планування завершень. Старіші producer без цього поля зберігають консервативну звичайну межу. Дивіться [планування завершень](./server-config-reference.md#rust-completion-planning) щодо кваліфікованої пари з native3.9.1 та меж розміщення payload.
+Rust SDK 4.16 використовує явний бюджет Server `limits.max_workflow_task_completion_bytes` для планування завершень. Старіші producer без цього поля зберігають консервативну звичайну межу. Дивіться [планування завершень](./server-config-reference.md#rust-completion-planning) щодо кваліфікованої пари з native 3.9.1 та меж розміщення payload.
 
 ## Строки очікування умови та оновлення worker {#condition-wait-deadlines}
 
@@ -235,7 +235,7 @@ Ok(())
 
 Одне клієнтське спостереження включає внутрішні повтори транспорту/storage admission та обробку відповіді/payload; окремі виклики застосунку чи worker рахуються окремо. Лінивий ітератор спостерігає кожну отриману сторінку. Poll worker включає керовані retry/backoff і розрізняє `task`, `empty`, `backpressure`, `error`. Результати task `completed`, `failed`, `expired` описують обробку dispatch, а не завершення workflow. Це спостереження процесу, не durable-лічильники, одиниці оплати чи schedule-to-start latency; аварійна втрата процесу може втратити останній зразок.
 
-Rust SDK 4.16 додає сьомий інструмент `durable_workflow_worker_task_schedule_to_start_seconds` лише з тегами `task_kind` і `task_queue`. Він записує в секундах виміряну Server затримку від готовності до claim, коли producer оголошує `claimed_task_ready_age` і надає коректний `ready_age_ms`. Відсутні, некоректні чи непідтримувані дані не дають зразка; SDK ніколи не вигадує нуль. [Опубліковані контролі4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) кваліфікують усі сім метрик, ready-age workflow/активностей і адаптер Prometheus.
+Rust SDK 4.16 додає сьомий інструмент `durable_workflow_worker_task_schedule_to_start_seconds` лише з тегами `task_kind` і `task_queue`. Він записує в секундах виміряну Server затримку від готовності до claim, коли producer оголошує `claimed_task_ready_age` і надає коректний `ready_age_ms`. Відсутні, некоректні чи непідтримувані дані не дають зразка; SDK ніколи не вигадує нуль. [Опубліковані контролі 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) кваліфікують усі сім метрик, ready-age workflow/активностей і адаптер Prometheus.
 
 Для офіційного Prometheus adapter увімкніть необов’язковий Cargo feature `metrics-prometheus`. Цей приклад використовує опублікований рецепт залежностей:
 
diff --git a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 8807760dd1f..e9c2b450c97 100644
--- a/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/uk/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -442,13 +442,13 @@ runtime також діють. Рядок ID workflow стосується ок
 
 Нативний runtime 3.9.1 публікує фактичний бюджет як `limits.max_workflow_task_completion_bytes` у cluster info. Для обох маршрутів завершення він вимірює все закодоване JSON-тіло запиту разом з оболонками, метаданими й командами. Використовуйте це значення, а не множник, виведений з версії, чи суму декодованих аргументів. Межі окремих значень та звичайних маршрутів не змінюються. Поле не надає додаткових прав на завантаження зовнішніх payload або розміщення посилань.
 
-Планувальники SDK мають дотримуватися позитивної опублікованої межі, навіть якщо вона нижча за звичайну. Відсутнє поле зберігає консервативний запасний варіант; явно некоректне, null, нульове, від’ємне або неціле значення відхиляє планування до завантаження. Звичайні маршрути ігнорують це невикористане поле завершення.
+Планувальник завершень Rust SDK 4.16 дотримується позитивної опублікованої межі, навіть якщо вона нижча за звичайну. Відсутнє поле зберігає консервативний запасний варіант; явно некоректне, null, нульове, від’ємне або неціле значення відхиляє планування до завантаження. Звичайні маршрути ігнорують це невикористане поле завершення.
 
 Більше завершення відхиляється з `413 payload_too_large` і `limit_kind: workflow_task_completion_bytes` ще до того, як щось буде записано. Повторне відтворення завдання дає ті самі команди, тож повторне надсилання завершення отримає ту саму відмову. Коли PHP SDK 3.17.0 або новіший отримує цю типізовану відмову, він не надсилає запит завершення повторно: worker один раз завершує запуск помилкою через команду `fail_workflow`, повідомлення якої починається з `Structural limit exceeded: workflow_task_completion_bytes:` і називає обидва розміри, а Server записує помилку з `failure_category = structural_limit`.
 
 Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану відмову. На Server 3.8.0 опублікований контроль Python отримав `httpx.ReadError` до HTTP 413 і залишив workflow в очікуванні. Нативний runtime 3.9.1 виправляє відповідь обмеженим відкиданням решти запиту: щонайбільше 64 MiB за щонайбільше дві секунди перед початковою відмовою та закриттям з’єднання. Завантаження поза будь-якою з цих меж і далі можуть мати транспортні помилки.
 
-Опублікований Python SDK 2.17.1 із кваліфікованим нативним Server 3.9.1 (linux/amd64, SQLite) тепер проходить [контролі реально встановленого Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out 300 × 10 KB у межах бюджету, одна типізована 413 і один структурний збій без часткових активностей для завеликого завершення, а потім успішне завдання на тому самому Worker. Це кваліфікує саме цю пару Python/Server. PHP потребує власної перевірки встановленого пакета; Rust4.16 кваліфіковано нижче. Спільне #228 залишається відкритим. Перевірка ключів запитів у спільному #216 є окремою.
+Опублікований Python SDK 2.17.1 із кваліфікованим нативним Server 3.9.1 (linux/amd64, SQLite) тепер проходить [контролі реально встановленого Worker](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512): fan-out 300 × 10 KB у межах бюджету, одна типізована 413 і один структурний збій без часткових активностей для завеликого завершення, а потім успішне завдання на тому самому Worker. Це кваліфікує саме цю пару Python/Server. PHP потребує власної перевірки встановленого пакета; Rust 4.16 кваліфіковано нижче. Спільне #228 залишається відкритим. Перевірка ключів запитів у спільному #216 є окремою.
 
 Щоб завершення вкладалося в ліміт:
 
@@ -458,7 +458,7 @@ Python SDK 2.17 і Rust SDK 4.15 обробляють типізовану ві
 
 #### Планування команд Rust {#rust-completion-planning}
 
-Rust SDK 4.16 використовує явний позитивний бюджет завершення, оголошений producer. [Опубліковані контролі4.16/native3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) проходять inline fan-out 300 × 10 KB без зовнішнього сховища, завеликий пакет 60 × 450 KB зі структурним збоєм без часткових активностей і успішне наступне завдання на тому самому Worker. Без явного поля старіші producer зберігають консервативну звичайну межу. Більший бюджет не надає нових прав на завантаження чи розміщення посилань; аргументи команд продовження активності залишаються inline. Ці контролі не кваліфікують повтори з ключами зі спільного #216 або нативне очищення за тайм-аутом.
+Rust SDK 4.16 використовує явний позитивний бюджет завершення, оголошений producer. [Опубліковані контролі 4.16/native 3.9.1](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671) (linux/amd64, SQLite) проходять inline fan-out 300 × 10 KB без зовнішнього сховища, завеликий пакет 60 × 450 KB зі структурним збоєм без часткових активностей і успішне наступне завдання на тому самому Worker. Без явного поля старіші producer зберігають консервативну звичайну межу. Більший бюджет не надає нових прав на завантаження чи розміщення посилань; аргументи команд продовження активності залишаються inline. Ці контролі не кваліфікують повтори з ключами зі спільного #216 або нативне очищення за тайм-аутом.
 
 ## Docker bootstrap та походження пакета {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/uk/source-hashes.json b/i18n/uk/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/uk/source-hashes.json
+++ b/i18n/uk/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/python.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/python.md
index 11942716ec1..c8a57509842 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/python.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/python.md
@@ -340,8 +340,8 @@ driver = external_storage_driver_from_policy(
 | `await client.describe_workflow_run(workflow_id, run_id)` | `WorkflowRun` | `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.get_history(workflow_id, run_id)` | 已解码历史负载 | `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.export_history(workflow_id, run_id)` | 已解码归档历史负载 | `WorkflowNotFound`, 认证/Server 错误 |
-| `await client.signal_workflow(workflow_id, signal_name, args=None)` | `None` | `WorkflowNotFound`, `InvalidArgument`, 认证/Server 错误 |
-| `await client.query_workflow(workflow_id, query_name, args=None)` | 已解码查询结果 | `QueryFailed`, `WorkflowNotFound`, 认证/Server 错误 |
+| `await client.signal_workflow(workflow_id, signal_name, args=None)` | 接纳回执 (`dict`) | `WorkflowNotFound`, `InvalidArgument`, 认证/Server 错误 |
+| `await client.query_workflow(workflow_id, query_name, args=None)` | 查询回执 (`dict`) | `QueryFailed`, `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.update_workflow(workflow_id, update_name, args=None, ...)` | 更新回执（`dict`） | `UpdateRejected`, `UpdateValidationFailed`, `UpdateFailed`, `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.cancel_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.terminate_workflow(workflow_id, reason=None)` | `None` | `WorkflowNotFound`, 认证/Server 错误 |
@@ -349,6 +349,8 @@ driver = external_storage_driver_from_policy(
 | `await client.archive_workflow(workflow_id, reason=None)` | `WorkflowCommandResult` | `WorkflowNotFound`, 认证/Server 错误 |
 | `await client.get_result(handle, poll_interval=0.5, timeout=30.0)` | 已解码工作流输出 | `WorkflowFailed`, `WorkflowCancelled`, `WorkflowTerminated`, `TimeoutError` |
 
+`signal_workflow` 返回包含 `request_id` 的接纳回执。`query_workflow` 和 `WorkflowHandle.query` 返回查询回执；通过 `receipt["result"]` 读取解码后的处理器值，包括成功返回的 `None`。参阅 [Python 客户端指南](https://python.durable-workflow.com/reference/client/)。
+
 `update_workflow` 默认为 `wait_for="accepted"`。其回执可能包含 `update_status="accepted"` 和 `result=None`。使用 `wait_for="completed"` 时，`wait_timeout_seconds` 限制等待时间。等待到期后，回执仍为已接受，并设置 `wait_timed_out=True`。只有 `update_status="completed"` 才表示结果已完成，包括 `None`。请保留 `update_id`，以便[稍后读取结果](https://python.durable-workflow.com/reference/client/#read-an-update-outcome)。
 
 `start_workflow` 接受 `workflow_type`、`task_queue`、可选 `workflow_id`、可选 `input`、`duplicate_policy`、`memo`、`search_attributes`、`business_key`、`execution_timeout_seconds` 和 `run_timeout_seconds`。所有调用方负载在越过 HTTP 边界前都进行 Avro 封装。
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
index 31435398e50..7a7fa7c3cbc 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/rust.md
@@ -81,7 +81,7 @@ Server 在主版本 `1` 内协商 Worker 协议头：公布 `1.N` 的 Server 仅
 
 Rust SDK 4.15 新增 `Client::update_outcome` 和 `Client::update_outcome_receipt`，用于按 ID 读取已接受的更新，不重新提交。这些方法要求 `capabilities.update_outcome_reads`（native Server 3.6.0 及更高版本）。`update_outcome` 对尚未完成的更新返回 `Error::UpdateStillPending`。已完成的 null 结果为 `Ok(Value::Null)`。回执保留明确的 `update_status`。Rust 接口见 [Client API](https://rust.durable-workflow.com/durable_workflow/struct.Client.html#method.update_outcome)。
 
-Rust SDK 4.16 使用 Server 显式提供的 `limits.max_workflow_task_completion_bytes` 预算规划完成请求。没有该字段的旧 producer 继续使用保守的普通上限。经过验证的 native3.9.1 组合及 payload 位置限制见[完成规划](./server-config-reference.md#rust-completion-planning)。
+Rust SDK 4.16 使用 Server 显式提供的 `limits.max_workflow_task_completion_bytes` 预算规划完成请求。没有该字段的旧 producer 继续使用保守的普通上限。经过验证的 native 3.9.1 组合及 payload 位置限制见[完成规划](./server-config-reference.md#rust-completion-planning)。
 
 ## 条件等待期限与 Worker 升级 {#condition-wait-deadlines}
 
@@ -170,7 +170,7 @@ Ok(())
 
 一次客户端观测包含内部传输/storage admission 重试及响应/payload 处理；应用或 worker 管理的独立调用分别计量。惰性迭代器按所请求的每页观测。worker poll 包含管理的 retry/backoff，区分 `task`、`empty`、`backpressure`、`error`。任务结果 `completed`、`failed`、`expired` 描述任务处理，不表示工作流终态。这是进程观测，不是持久计数、计费单位或 schedule-to-start 延迟；进程突然丢失可能遗漏最终样本。
 
-Rust SDK 4.16 添加第七个指标 `durable_workflow_worker_task_schedule_to_start_seconds`，仅带 `task_kind` 和 `task_queue` 标签。当 producer 公布 `claimed_task_ready_age` 并提供有效的 `ready_age_ms` 时，它以秒记录 Server 计量的“可执行到 claim”延迟。数据缺失、无效或不受支持时不产生样本；SDK 不会编造零值。[已发布4.16/native3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）验证了全部七个指标、workflow/activity ready-age 观测和 Prometheus 适配器。
+Rust SDK 4.16 添加第七个指标 `durable_workflow_worker_task_schedule_to_start_seconds`，仅带 `task_kind` 和 `task_queue` 标签。当 producer 公布 `claimed_task_ready_age` 并提供有效的 `ready_age_ms` 时，它以秒记录 Server 计量的“可执行到 claim”延迟。数据缺失、无效或不受支持时不产生样本；SDK 不会编造零值。[已发布 4.16/native 3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）验证了全部七个指标、workflow/activity ready-age 观测和 Prometheus 适配器。
 
 使用官方 Prometheus 适配器时，启用可选 Cargo feature `metrics-prometheus`。示例采用已发布的依赖配置：
 
diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
index 22c81a70f4e..7f18f63a04a 100644
--- a/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
+++ b/i18n/zh-Hans/docusaurus-plugin-content-docs/current/polyglot/server-config-reference.md
@@ -328,13 +328,13 @@ PHP Server 2.x 的可配置限制请使用已记录的 `DW_*` 设置。控制器
 
 原生 3.9.1 在 cluster info 中通过 `limits.max_workflow_task_completion_bytes` 公布实际预算。它对两个完成路由都计量整个编码后 JSON 请求体，包括 envelope、元数据和命令。应使用该值，而不是按 Server 版本推断倍数或累加解码后的参数大小。单个值和普通路由的上限不变。此字段不会授予额外的外部 payload 上传权限或引用放置权限。
 
-SDK 规划器必须遵守公布的正整数上限，即使它低于普通上限。字段缺失时保留保守的回退行为；显式格式错误、null、零、负数或非整数值会在上传前拒绝完成规划。普通路由忽略此未使用的完成字段。
+Rust SDK 4.16 完成规划器遵守公布的正整数上限，即使它低于普通上限。字段缺失时保留保守的回退行为；显式格式错误、null、零、负数或非整数值会在上传前拒绝完成规划。普通路由忽略此未使用的完成字段。
 
 更大的完成请求会在记录任何内容之前以 `413 payload_too_large` 和 `limit_kind: workflow_task_completion_bytes` 被拒绝。重放该任务会生成相同的命令，因此重新发送完成请求会得到同样的拒绝。PHP SDK 3.17.0 及以上在收到这种类型化拒绝后不会重新发送完成请求：Worker 用一条 `fail_workflow` 命令让运行失败一次，其消息以 `Structural limit exceeded: workflow_task_completion_bytes:` 开头并给出两个大小，Server 以 `failure_category = structural_limit` 记录该失败。
 
 Python SDK 2.17 和 Rust SDK 4.15 包含类型化拒绝处理。Server 3.8.0 的已发布 Python 验证在收到 HTTP 413 前遇到 `httpx.ReadError`，使 workflow 保持待定。原生 3.9.1 通过有界丢弃请求余下数据修复此响应路径：最多 64 MiB、最多两秒，然后返回原始拒绝并关闭连接。超出任一边界的上传仍可能遇到传输错误。
 
-已发布的 Python SDK 2.17.1 与经过验证的原生 Server 3.9.1（linux/amd64、SQLite）现已通过[实际安装 Worker 的验证](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)：预算内 300 × 10 KB fan-out；过大的完成请求只产生一次类型化 413 和一次结构性失败，部分 activity 为零；随后同一 Worker 成功执行后续任务。此结果只验证这个确切的 Python/Server 组合。PHP 仍需独立的安装后验证；Rust4.16 的验证如下。共享 #228 仍未关闭。共享 #216 的请求键验证是独立的。
+已发布的 Python SDK 2.17.1 与经过验证的原生 Server 3.9.1（linux/amd64、SQLite）现已通过[实际安装 Worker 的验证](https://github.com/durable-workflow/.github/issues/228#issuecomment-6853834512)：预算内 300 × 10 KB fan-out；过大的完成请求只产生一次类型化 413 和一次结构性失败，部分 activity 为零；随后同一 Worker 成功执行后续任务。此结果只验证这个确切的 Python/Server 组合。PHP 仍需独立的安装后验证；Rust 4.16 的验证如下。共享 #228 仍未关闭。共享 #216 的请求键验证是独立的。
 
 要让完成请求保持在上限之内：
 
@@ -344,7 +344,7 @@ Python SDK 2.17 和 Rust SDK 4.15 包含类型化拒绝处理。Server 3.8.0 的
 
 #### Rust 命令规划 {#rust-completion-planning}
 
-Rust SDK 4.16 使用 producer 公布的显式正整数完成预算。[已发布4.16/native3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）通过了无外部存储的 300 × 10 KB inline fan-out、过大的 60 × 450 KB 批次产生结构性失败且部分 activity 为零、随后同一 Worker 的后续任务成功。缺少显式字段时，旧 producer 继续使用保守的普通上限。更大的预算不授予新上传权限或引用位置权限；activity continuation 命令参数仍须 inline。这些验证不代表共享 #216 的请求键重试或原生超时清理已通过。
+Rust SDK 4.16 使用 producer 公布的显式正整数完成预算。[已发布 4.16/native 3.9.1 的验证](https://github.com/durable-workflow/sdk-rust/pull/258#issuecomment-6854288671)（linux/amd64、SQLite）通过了无外部存储的 300 × 10 KB inline fan-out、过大的 60 × 450 KB 批次产生结构性失败且部分 activity 为零、随后同一 Worker 的后续任务成功。缺少显式字段时，旧 producer 继续使用保守的普通上限。更大的预算不授予新上传权限或引用位置权限；activity continuation 命令参数仍须 inline。这些验证不代表共享 #216 的请求键重试或原生超时清理已通过。
 
 ## Docker 初始化与来源信息 {#docker-bootstrap-and-provenance}
 
diff --git a/i18n/zh-Hans/source-hashes.json b/i18n/zh-Hans/source-hashes.json
index 01a6ab2308e..be578197d37 100644
--- a/i18n/zh-Hans/source-hashes.json
+++ b/i18n/zh-Hans/source-hashes.json
@@ -84,12 +84,12 @@
   "polyglot/polling-patterns.md": "30875099a23731c6c471b481a771378acc6ff57eed2fda4405a509057534c989",
   "polyglot/portable-worker-affinity.md": "40973c6a31a76845b4f95e9a505e68ad76abd5174bbdccf37993cdebc8904959",
   "polyglot/prerelease-history-migration.md": "a57f05f492228a8a67791f9152648a1e5f80856325b78777cf63b6ef49b7413c",
-  "polyglot/python.md": "7e31563bf15d1f7f1bd1647b70644ef5e72b2c912c566e72e9b1cc4a7fe19d89",
+  "polyglot/python.md": "6dadcd0fdf57ad9ca8bfc8eded74f870bf62a099ae16c2767338a2c74bb07b54",
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "786ff80e79693d7f17168822792ca68e51259087d4694da4a08a098c95339fe6",
+  "polyglot/server-config-reference.md": "86cdcdac61326d12675b645bca90b2b18b107ee3d9ab8d839aef2eca823c40f0",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
   "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",