Adopt Server 3.10 and Chart 2.0 schema and dispatch-summary contracts

docs/deployment.md

@@ -268,6 +268,33 @@ 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.10.0 {#native-schema-upgrade-3-10}
+
+Native 3.10.0 requires an explicit additive schema upgrade from 3.9.x:
+
+| Backend | Schema transition from 3.9.x |
+|---|---|
+| SQLite | 13 → 14 |
+| PostgreSQL | 14 → 15 |
+| MariaDB | 14 → 15 |
+| MySQL | 15 → 16 |
+
+Stop every Server replica, keep the database running, and back up the database
+and external-payload storage. Select the 3.10.0 image and run its
+`schema-upgrade` once before restarting every replica on the same version.
+Check readiness, reported version and worker registration. Startup does not
+upgrade an old schema automatically. Older versions require the intervening
+steps too. The [published 3.10.0 upgrade instructions](https://github.com/durable-workflow/server/releases/tag/3.10.0#upgrade-and-rollback)
+provide the Compose commands. Worker protocol 1.20 and control plane 2 are unchanged.
+
+The nullable schedule summary is not backfilled from legacy action arrays.
+Existing schedules remain unavailable until an owning transition records a
+valid summary; see [dispatch-summary authority](./polyglot/server-api-reference.md#schedule-dispatch-summary).
+MySQL and MariaDB resume interrupted upgrades; SQLite and PostgreSQL apply the
+step transactionally. Rollback to an older binary requires restoring the
+pre-upgrade database and storage backup. Do not run an older binary against
+the newer schema.
+
 ### Upgrading to Server 3.9.2 {#native-schema-upgrade-3-9}
 
 Upgrading from native 3.8.x or earlier requires a schema upgrade on every

docs/polyglot/server-api-reference.md

@@ -849,6 +849,37 @@ Search attribute names and types are part of the namespace search contract.
 Avoid using high-cardinality attributes for operator dashboards or metric
 labels.
 
+### Schedule dispatch-summary authority {#schedule-dispatch-summary}
+
+Published native Server 3.10.0 adds a complete `dispatch_summary` with
+`version: 1`, `state`, `last_outcome` and `buffered_actions_count` to schedule
+list items and describe responses. Older producers omit it; an empty list
+does not establish support. Inspect the complete field rather than infer
+support from a version. The [tagged schedule contract](https://github.com/durable-workflow/server/blob/3.10.0/docs/server-reference.md#schedules)
+defines the exact shape.
+
+| State | Last outcome | Current buffer count |
+|---|---|---|
+| `known` | Complete recorded dispatch | Integer from 0 through 9007199254740991 |
+| `never` | `null`, established only by new creation | `0` |
+| `unavailable` | `null`, including legacy or invalid stored authority | `null` |
+
+Known outcomes are `started`, `buffered`, `skipped` or `failed`, with the
+complete outcome ID, recording time, reason and applicable workflow/run
+identities. The current buffer count is separate: a later drain can leave a
+recorded buffered outcome with count zero. The latest workflow's execution
+status is also separate; a Started dispatch may point to a workflow that later Failed.
+
+Each summary is bounded to 4096 serialized UTF-8 bytes. A transition that
+cannot record the complete contract stores unavailable authority, without
+truncating its reason or changing the scheduling operation. Absent, null,
+partial or unsupported data is not v1 authority. A valid unavailable summary
+overrides legacy evidence. A later describe owns the whole summary, including
+absence or null; never merge it field by field with an older list result.
+Schema upgrades do not reconstruct authority from legacy arrays. The bounded
+list-page read needs no per-row describe requests. This is producer behavior;
+Waterline's published consumer and visible-refresh acceptance remain separately qualified.
+
 ### Schedule list filters and continuation {#schedule-list-filters}
 
 `GET /api/schedules` reads the request namespace. The [normal published PHP Server qualification](https://github.com/durable-workflow/durable-workflow.github.io/issues/402#issuecomment-6370122227) verifies combined filters and continuation. Send the following query parameters, with normal URL encoding:

docs/polyglot/server.md

@@ -175,10 +175,10 @@ 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.2 require the
-[explicit schema upgrade](../deployment.md#native-schema-upgrade-3-9) before restart.
-From 3.9.0 or 3.9.1, no additional schema step is needed; follow the same
-backup, restart and readiness checks.
+Upgrading to native 3.10.0, including from 3.9.x, requires the
+[explicit schema upgrade](../deployment.md#native-schema-upgrade-3-10) before restart.
+Older versions also need their intervening schema steps. Back up both the
+database and external-payload storage; rollback restores that backup.
 
 ### Ports
 

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.10.0 {#native-schema-upgrade-3-10}
+
+Native 3.10.0 benötigt von 3.9.x ein explizites additives Schema-Upgrade.
+
+| Backend | Schemaübergang von 3.9.x |
+|---|---|
+| SQLite | 13 → 14 |
+| PostgreSQL | 14 → 15 |
+| MariaDB | 14 → 15 |
+| MySQL | 15 → 16 |
+
+Stoppen Sie alle Server-Replikate, lassen Sie die Datenbank laufen und sichern Sie Datenbank sowie externen Payload-Speicher. Wählen Sie das 3.10.0-Image und führen Sie dessen `schema-upgrade` einmal aus, bevor alle Replikate mit derselben Version neu starten. Prüfen Sie Readiness, gemeldete Version und Worker-Registrierung. Der Start aktualisiert kein altes Schema automatisch. Ältere Versionen benötigen auch die Zwischenschritte. Die [veröffentlichten 3.10.0-Upgrade-Anweisungen](https://github.com/durable-workflow/server/releases/tag/3.10.0#upgrade-and-rollback) enthalten die Compose-Befehle. Worker-Protokoll 1.20 und Control Plane 2 bleiben unverändert.
+
+Die nullable Schedule-Zusammenfassung wird nicht aus alten Action-Arrays nachgetragen. Bestehende Schedules bleiben unverfügbar, bis ein zuständiger Übergang eine gültige Zusammenfassung aufzeichnet; siehe [Dispatch-Summary-Autorität](./polyglot/server-api-reference.md#schedule-dispatch-summary). MySQL und MariaDB setzen unterbrochene Upgrades fort; SQLite und PostgreSQL wenden den Schritt transaktional an. Rollback auf ein älteres Binary erfordert die Wiederherstellung der Datenbank- und Speicher-Sicherung vor dem Upgrade. Führen Sie kein älteres Binary mit dem neueren Schema aus.
+
 ### Upgrade auf Server 3.9.2 {#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:

i18n/de/docusaurus-plugin-content-docs/current/polyglot/server-api-reference.md

@@ -797,6 +797,20 @@ Zeitplanrouten sind Control-Plane-Routen.
 Suchattributnamen und -typen gehören zum Namespace-Suchvertrag. Vermeiden Sie
 Attribute mit hoher Kardinalität für Betriebsdashboards oder Metrikbezeichnungen.
 
+### Dispatch-Summary-Autorität für Schedules {#schedule-dispatch-summary}
+
+Der veröffentlichte native Server 3.10.0 ergänzt Schedule-Listeneinträge und Describe-Antworten um ein vollständiges `dispatch_summary` mit `version: 1`, `state`, `last_outcome` und `buffered_actions_count`. Ältere Produzenten lassen es weg; eine leere Liste belegt keine Unterstützung. Prüfen Sie das vollständige Feld, statt Unterstützung aus einer Version abzuleiten. Der [getaggte Schedule-Vertrag](https://github.com/durable-workflow/server/blob/3.10.0/docs/server-reference.md#schedules) definiert die genaue Form.
+
+| Zustand | Letztes Ergebnis | Aktueller Pufferstand |
+|---|---|---|
+| `known` | Vollständig aufgezeichneter Dispatch | Ganzzahl von 0 bis 9007199254740991 |
+| `never` | `null`, nur durch Neuanlage belegt | `0` |
+| `unavailable` | `null`, einschließlich alter oder ungültiger gespeicherter Autorität | `null` |
+
+Bekannte Ergebnisse sind `started`, `buffered`, `skipped` oder `failed`, mit vollständiger Ergebnis-ID, Aufzeichnungszeit, Begründung und zutreffenden Workflow-/Run-Identitäten. Der aktuelle Pufferstand ist separat: Nach späterem Leeren kann ein aufgezeichnetes buffered-Ergebnis mit Zählerstand 0 verbleiben. Der Ausführungsstatus des neuesten Workflows ist ebenfalls separat; ein Started-Dispatch kann auf einen später Failed-Workflow zeigen.
+
+Jede Zusammenfassung ist auf 4096 serialisierte UTF-8-Bytes begrenzt. Kann ein Übergang den vollständigen Vertrag nicht speichern, wird unverfügbare Autorität gespeichert, ohne Begründungskürzung oder Änderung der Scheduling-Operation. Fehlende, null, unvollständige oder nicht unterstützte Daten sind keine v1-Autorität. Eine gültige unavailable-Zusammenfassung überschreibt alte Nachweise. Ein späteres Describe besitzt die gesamte Zusammenfassung einschließlich Fehlen oder null; mischen Sie sie nie feldweise mit einem älteren Listenergebnis. Schema-Upgrades rekonstruieren keine Autorität aus alten Arrays. Die begrenzte Listenseite benötigt keine Describe-Anfrage pro Zeile. Dies ist Produzentenverhalten; Waterlines veröffentlichter Consumer und sichtbare Aktualisierung werden separat qualifiziert.
+
 ### Filter und Fortsetzung für Zeitplanlisten {#schedule-list-filters}
 
 `GET /api/schedules` liest den Namespace der Anfrage. Die [Prüfung des regulär veröffentlichten PHP Servers](https://github.com/durable-workflow/durable-workflow.github.io/issues/402#issuecomment-6370122227) bestätigt kombinierte Filter und Fortsetzung. Senden Sie folgende Abfrageparameter mit normaler URL-Kodierung:

i18n/de/docusaurus-plugin-content-docs/current/polyglot/server.md

@@ -135,8 +135,7 @@ 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.2 benötigen vor dem Neustart das [explizite Schema-Upgrade](../deployment.md#native-schema-upgrade-3-9).
-Von 3.9.0 oder 3.9.1 ist kein zusätzlicher Schemaschritt nötig; führen Sie dieselben Backup-, Neustart- und Readiness-Prüfungen aus.
+Ein Upgrade auf native 3.10.0, auch von 3.9.x, erfordert vor dem Neustart das [explizite Schema-Upgrade](../deployment.md#native-schema-upgrade-3-10). Ältere Versionen benötigen auch ihre Zwischenschritte. Sichern Sie Datenbank und externen Payload-Speicher; ein Rollback stellt diese Sicherung wieder her.
 
 ### Ports {#ports}
 

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": "dbc8ff149cea02d1db474e4decd83ee12692a59087d86e8fcc7d7655206961e9",
+  "deployment.md": "adf903d1e27b5ef6291020571cde52f176dfc0ca8addbd72e5da3e0cd88b62e5",
   "failures-and-recovery.md": "a240727af9539cca9cceb6ab3ddea545c95f21402813365442929ea05c09e70c",
   "features/activity-execution-model.md": "e8c37520ae46a7efb30438f4fc06bf893c1df430cb1f92c48963697adaf09082",
   "features/cancel-and-terminate.md": "cedd1e6c51dfa551e00edc1d39739ff1f67d558d2a0be92143f478cb6111536b",
@@ -88,10 +88,10 @@
   "polyglot/runtime-migration.md": "5a78713bb8cb74aea58f6d5d826400d968a405f69c6ff17fdf2f7decb1d14b71",
   "polyglot/rust-cloud-quickstart.md": "2303434fc9302a81a8381ad4836423ef9952eb3201a4574c432254e3cb68c5f3",
   "polyglot/rust.md": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
-  "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
+  "polyglot/server-api-reference.md": "ecd6d358d6e5bde442ebf0e1ec8a072779089e2a5c4427e31eef646f42c6c03c",
   "polyglot/server-config-reference.md": "88f440db04a4636c1c2f88b3613c45b5b0cdf46aa27cf64c800f56feac59dfa5",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "a2404c130fdc8611eff4b8844729225b95292eafd4206145078c3fe270d2b30c",
+  "polyglot/server.md": "156d641693f44880b4003f0d20872dfda54f803f6a9415bbff3ddb37423ec66a",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",

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.10.0 {#native-schema-upgrade-3-10}
+
+El runtime nativo 3.10.0 requiere una actualización aditiva explícita del esquema desde 3.9.x.
+
+| Backend | Transición de esquema desde 3.9.x |
+|---|---|
+| SQLite | 13 → 14 |
+| PostgreSQL | 14 → 15 |
+| MariaDB | 14 → 15 |
+| MySQL | 15 → 16 |
+
+Detenga todas las réplicas del Server, mantenga la base activa y haga una copia de la base y del almacenamiento de payloads externos. Seleccione la imagen 3.10.0 y ejecute su `schema-upgrade` una vez antes de reiniciar todas las réplicas con la misma versión. Verifique readiness, versión declarada y registro de workers. El inicio no actualiza esquemas antiguos automáticamente. Las versiones anteriores también requieren los pasos intermedios. Las [instrucciones publicadas de actualización a 3.10.0](https://github.com/durable-workflow/server/releases/tag/3.10.0#upgrade-and-rollback) incluyen los comandos Compose. El protocolo de workers 1.20 y el plano de control 2 no cambian.
+
+El resumen nullable de la programación no se rellena a partir de arrays antiguos de acciones. Las programaciones existentes siguen no disponibles hasta que una transición responsable registre un resumen válido; vea la [autoridad del resumen de despacho](./polyglot/server-api-reference.md#schedule-dispatch-summary). MySQL y MariaDB reanudan actualizaciones interrumpidas; SQLite y PostgreSQL aplican el paso en una transacción. Volver a un binario anterior exige restaurar la copia previa de base y almacenamiento. No ejecute un binario antiguo contra el esquema nuevo.
+
 ### Actualizar a Server 3.9.2 {#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`:

i18n/es/docusaurus-plugin-content-docs/current/polyglot/server-api-reference.md

@@ -611,6 +611,20 @@ Las programaciones son rutas del plano de control.
 
 Los nombres y tipos de atributos forman parte del contrato de búsqueda del espacio. Evita atributos de alta cardinalidad en paneles operativos o etiquetas de métricas.
 
+### Autoridad del resumen de despacho de programaciones {#schedule-dispatch-summary}
+
+El Server nativo 3.10.0 publicado añade un `dispatch_summary` completo con `version: 1`, `state`, `last_outcome` y `buffered_actions_count` a los elementos de lista y respuestas describe de programaciones. Los productores antiguos lo omiten; una lista vacía no demuestra soporte. Inspeccione el campo completo en vez de inferir soporte por versión. El [contrato de programaciones etiquetado](https://github.com/durable-workflow/server/blob/3.10.0/docs/server-reference.md#schedules) define la forma exacta.
+
+| Estado | Último resultado | Recuento actual del búfer |
+|---|---|---|
+| `known` | Despacho completo registrado | Entero de 0 a 9007199254740991 |
+| `never` | `null`, establecido solo al crear | `0` |
+| `unavailable` | `null`, incluida autoridad antigua o almacenada inválida | `null` |
+
+Los resultados conocidos son `started`, `buffered`, `skipped` o `failed`, con ID de resultado, instante de registro, motivo e identidades workflow/run aplicables completos. El recuento actual del búfer es independiente: vaciarlo después puede dejar un resultado buffered registrado con recuento cero. El estado de ejecución del workflow más reciente también es independiente; un despacho Started puede apuntar a un workflow que después Failed.
+
+Cada resumen está limitado a 4096 bytes UTF-8 serializados. Una transición incapaz de registrar el contrato completo guarda autoridad no disponible, sin truncar el motivo ni cambiar la operación de programación. Datos ausentes, null, parciales o no soportados no son autoridad v1. Un resumen unavailable válido prevalece sobre evidencia antigua. Un describe posterior es dueño del resumen completo, incluso ausencia o null; nunca lo combine campo por campo con una lista anterior. Las actualizaciones de esquema no reconstruyen autoridad a partir de arrays antiguos. La lectura acotada de la página no necesita describir cada fila. Es comportamiento del productor; el consumidor publicado y la actualización visible de Waterline se cualifican por separado.
+
 ### Filtros y continuación de listas de programaciones {#schedule-list-filters}
 
 `GET /api/schedules` lee el espacio de nombres de la solicitud. La [verificación de PHP Server publicado mediante instalación normal](https://github.com/durable-workflow/durable-workflow.github.io/issues/402#issuecomment-6370122227) confirma los filtros combinados y la continuación. Envíe estos parámetros de consulta con la codificación URL habitual:

i18n/es/docusaurus-plugin-content-docs/current/polyglot/server.md

@@ -124,8 +124,7 @@ 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.2 exige la [actualización explícita del esquema](../deployment.md#native-schema-upgrade-3-9) antes de reiniciar.
-Desde 3.9.0 o 3.9.1 no hace falta otro paso de esquema; siga las mismas comprobaciones de copia, reinicio y readiness.
+Actualizar a native 3.10.0, incluso desde 3.9.x, exige la [actualización explícita del esquema](../deployment.md#native-schema-upgrade-3-10) antes de reiniciar. Las versiones anteriores también necesitan sus pasos intermedios. Copie tanto la base como el almacenamiento de payloads externos; la reversión restaura esa copia.
 
 ### Puertos {#ports}