Adopt Server 3.9.2 and Chart 1.7.1 with corrected receipt guidance

docs/deployment.md

@@ -268,7 +268,7 @@ 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 to Server 3.9.2 {#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:
@@ -281,18 +281,22 @@ backend. Server 3.9.1 adds the empty `dw_command_intents` table:
 | 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
+Server storage, then select and pull the 3.9.2 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)
+[qualified 3.9.2 release instructions](https://github.com/durable-workflow/server/releases/tag/3.9.2#upgrade-and-rollback)
 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,
+From 3.9.0 or 3.9.1, no further schema step is needed: stop replicas, back up,
+select the new image, restart and verify readiness, version and worker
+registration. Physical schema and existing command/intent rows are unchanged.
+Rollback to 3.9.1 uses the same schema but restores the Unicode-key/receipt
+metadata defects and removes observation-owner hardening. 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.

docs/polyglot/server-config-reference.md

@@ -92,8 +92,16 @@ Readiness also returns 503 while database health can remain 200. The
 [published 3.9.1 file-consumer controls](https://github.com/durable-workflow/server/issues/951#issuecomment-6853859351)
 verify these cases and recovery after atomic file replacement. They do not
 qualify physical quota measurement or a production Cloud mapping. This is
-admission control, not a write fence or byte reservation. Owner-UID hardening
-and draining completion-upload work remain separate from this published scope.
+admission control, not a write fence or byte reservation.
+
+Native 3.9.2 additionally requires the already-opened observation descriptor to
+belong to root or the effective Server UID. A foreign owner fails closed as
+`storage_admission_unavailable`; the owner/type/mode/content checks use the same
+descriptor. Operators must still provide trusted ancestors and the intended
+read-only container mapping: the runtime does not enforce ancestor ownership.
+The [published 3.9.2 correction](https://github.com/durable-workflow/server/releases/tag/3.9.2#storage-admission-observation-ownership)
+does not establish physical collector or Cloud adoption acceptance and adds no
+draining completion-upload allowance.
 
 Native has no server-side task-queue lease or dispatch caps, budget groups,
 namespace request admission, namespace durable-state quotas or held-poll caps,
@@ -380,11 +388,23 @@ 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.
+Native 3.9.2 applies the existing 255 Unicode code-point limit to signal and
+update command keys throughout admission. A 255-character multibyte
+`request_id` is accepted; 256 characters are refused without admission. This
+corrects the [3.9.1 UTF-8 byte-count refusal](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056).
+Use the body `request_id` as the retry key; the HTTP `X-Request-Id` header is
+not a command key.
+
+Fresh keyed signal and accepted update receipts in 3.9.2 echo the literal
+`request_id` with `retained:false` and `intent_verified:true`. Retained receipts
+echo that key with `retained:true` and preserve the original command, run and
+update identities. Modern intent proof reports `intent_verified:true`;
+compatible pre-intent legacy readback reports `intent_verified:false`.
+Unkeyed and bridge receipts keep their existing behavior. The
+[published correction](https://github.com/durable-workflow/server/releases/tag/3.9.2#command-keys-and-receipts)
+does not establish every installed client cohort under
+[shared #216](https://github.com/durable-workflow/.github/issues/216); earlier
+3.9.1 failures must be rerun on the exact corrected tuple.
 
 The currently-configured values are published under `limits` on the `GET /api/cluster/info` response, so clients can discover them at runtime:
 

docs/polyglot/server.md

@@ -175,8 +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.1 require the
+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.
 
 ### Ports
 

i18n/de/docusaurus-plugin-content-docs/current/deployment.md

@@ -195,7 +195,7 @@ 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}
+### 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:
 
@@ -206,9 +206,9 @@ Ein Upgrade von native 3.8.x oder früher erfordert auf jedem Backend ein Schema
 | 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.
+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.2. 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.2](https://github.com/durable-workflow/server/releases/tag/3.9.2#upgrade-and-rollback) 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.
+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 oder 3.9.1 ist kein weiterer Schemaschritt nötig: Replikate stoppen, sichern, neues Image wählen, neu starten und Readiness, Version sowie Worker-Registrierung prüfen. Physisches Schema und vorhandene Command-/Intent-Zeilen bleiben unverändert. Ein Rollback auf 3.9.1 nutzt dasselbe Schema, stellt aber Unicode-Key-/Belegmetadatenfehler wieder her und entfernt die Beobachtungseigentümer-Härtung. 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}
 

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

@@ -62,7 +62,9 @@ Der native Server lehnt diese Einstellungen ab, sofern sie nicht den aufgeführt
 
 Der native Server akzeptiert, ignoriert aber: `DW_ADMIN_SIGNATURE_KEY`, `DW_AUTH_METHOD_HEADER`, `DW_AUTH_STATUS_HEADER`, `DW_BOOTSTRAP_DELAY_SECONDS`, `DW_BOOTSTRAP_RETRIES`, `DW_CALLER_LABEL_HEADER`, `DW_CALLER_TYPE_HEADER`, `DW_COMPRESSION_ENABLED`, `DW_DUE_TIMER_RECOVERY_SCAN_LIMIT`, `DW_EXPIRED_WORKFLOW_TASK_RECOVERY_TTL_SECONDS`, `DW_EXTERNAL_PAYLOAD_S3_ACCESS_KEY_ID`, `DW_EXTERNAL_PAYLOAD_S3_ENDPOINT`, `DW_EXTERNAL_PAYLOAD_S3_REGION`, `DW_EXTERNAL_PAYLOAD_S3_SECRET_ACCESS_KEY`, `DW_EXTERNAL_PAYLOAD_S3_SESSION_TOKEN`, `DW_EXTERNAL_PAYLOAD_S3_USE_PATH_STYLE_ENDPOINT`, `DW_MAX_HISTORY_EVENTS`, `DW_MAX_TASKS_PER_POLL`, `DW_OBSERVABILITY_BAGGAGE_ALLOWLIST`, `DW_OBSERVABILITY_CONTEXT_ENABLED`, `DW_OPERATOR_SIGNATURE_KEY`, `DW_PACKAGE_PROVENANCE_PATH`, `DW_POLLING_CACHE_PATH`, `DW_QUERY_TASK_POLL_MAX_CONCURRENT`, `DW_QUERY_TASK_POLL_MAX_CONCURRENT_PER_NAMESPACE`, `DW_SIGNATURE_KEY`, `DW_SQLITE_CLAIM_LOCK_TTL_SECONDS`, `DW_SQLITE_CLAIM_LOCK_WAIT_SECONDS`, `DW_V2_CACHE_VALIDATION_MODE`, `DW_V2_GUARDRAILS_BOOT`, `DW_V2_LIMIT_SEARCH_ATTRIBUTE_SIZE_BYTES`, `DW_V2_LIMIT_WARNING_THRESHOLD_PERCENT`, `DW_V2_MATCHING_ROLE_QUEUE_WAKE`, `DW_V2_TASK_DISPATCH_MODE`, `DW_V2_TASK_REPAIR_LOOP_THROTTLE_SECONDS`, `DW_V2_TENANCY_ENVIRONMENT`, `DW_V2_TENANCY_ORGANIZATION`, `DW_V2_TENANCY_PROJECT`, `DW_V2_UPDATE_WAIT_POLL_INTERVAL_MS`, `DW_V2_VALIDATE_CACHE_BACKEND`, `DW_WAKE_SIGNAL_TTL_SECONDS`, `DW_WORKER_LONG_POLL_MAX_CONCURRENT`, `DW_WORKER_LONG_POLL_MAX_CONCURRENT_PER_NAMESPACE`, `DW_WORKER_LONG_POLL_RESERVED_HTTP_WORKERS`, `DW_WORKER_POLL_INTERVAL_MS`, `DW_WORKER_POLL_SIGNAL_CHECK_INTERVAL_MS`, `DW_WORKER_SIGNATURE_KEY`.
 
-Native 3.9.1 unterstützt optionale Storage-Admission anhand einer vom Betreiber veröffentlichten lokalen Beobachtung. Setzen Sie `DW_STORAGE_ADMISSION_FILE` auf den absoluten Pfad und `DW_STORAGE_ADMISSION_SOURCE` auf die erwartete Quellidentität. `DW_STORAGE_ADMISSION_MAX_AGE_SECONDS` ist standardmäßig 15 (Bereich 1–300). Sind Pfad und Quelle beide nicht gesetzt, ist die Funktion deaktiviert. Fehlende, ungültige oder veraltete Beobachtungen verweigern neue Arbeit mit `503 storage_admission_unavailable`; `draining` oder `fenced` verweigern sie mit `503 storage_pressure`. Readiness liefert ebenfalls 503, während der Datenbankzustand 200 bleiben kann. Die [veröffentlichten Dateiverbraucher-Kontrollen für 3.9.1](https://github.com/durable-workflow/server/issues/951#issuecomment-6853859351) prüfen diese Fälle und die Erholung nach atomarem Dateiaustausch. Sie qualifizieren weder physische Kontingentmessung noch eine produktive Cloud-Zuordnung. Dies ist Admission-Control, keine Schreibsperre oder Byte-Reservierung. Owner-UID-Härtung und Completion-Uploads beim Draining bleiben außerhalb dieses veröffentlichten Umfangs.
+Native 3.9.1 unterstützt optionale Storage-Admission anhand einer vom Betreiber veröffentlichten lokalen Beobachtung. Setzen Sie `DW_STORAGE_ADMISSION_FILE` auf den absoluten Pfad und `DW_STORAGE_ADMISSION_SOURCE` auf die erwartete Quellidentität. `DW_STORAGE_ADMISSION_MAX_AGE_SECONDS` ist standardmäßig 15 (Bereich 1–300). Sind Pfad und Quelle beide nicht gesetzt, ist die Funktion deaktiviert. Fehlende, ungültige oder veraltete Beobachtungen verweigern neue Arbeit mit `503 storage_admission_unavailable`; `draining` oder `fenced` verweigern sie mit `503 storage_pressure`. Readiness liefert ebenfalls 503, während der Datenbankzustand 200 bleiben kann. Die [veröffentlichten Dateiverbraucher-Kontrollen für 3.9.1](https://github.com/durable-workflow/server/issues/951#issuecomment-6853859351) prüfen diese Fälle und die Erholung nach atomarem Dateiaustausch. Sie qualifizieren weder physische Kontingentmessung noch eine produktive Cloud-Zuordnung. Dies ist Admission-Control, keine Schreibsperre oder Byte-Reservierung.
+
+Native 3.9.2 verlangt zusätzlich, dass der bereits geöffnete Beobachtungsdeskriptor root oder der effektiven Server-UID gehört. Ein fremder Eigentümer wird mit `storage_admission_unavailable` abgewiesen; Eigentümer-, Typ-, Modus- und Inhaltsprüfungen verwenden denselben Deskriptor. Betreiber müssen weiterhin vertrauenswürdige Vorfahren und die vorgesehene schreibgeschützte Container-Zuordnung bereitstellen: Die Laufzeit erzwingt keine Eigentümerschaft der Vorfahren. Die [veröffentlichte 3.9.2-Korrektur](https://github.com/durable-workflow/server/releases/tag/3.9.2#storage-admission-observation-ownership) qualifiziert weder physischen Collector noch Cloud-Einsatz und erlaubt keine Completion-Uploads beim Draining.
 
 Der native Server hat keine serverseitigen Lease- oder Zustellungsgrenzen für Task-Warteschlangen, keine Budgetgruppen, keine Anfragezulassung pro Namespace, keine Kontingente für dauerhaften Namespace-Zustand und keine Grenzen für gehaltene Polls; ein natives Gegenstück gibt es dafür noch nicht. Jeder native Server-Prozess öffnet höchstens vier Datenbankverbindungen. Abfrageaufgaben haben eine feste Grenze von 16 ausstehenden oder geleasten Aufgaben pro Namespace; darüber hinaus werden neue Abfragen wie bei PHP mit HTTP `429` und `query_task_queue_full` abgelehnt. Diese Grenze ist nicht konfigurierbar. Um die Task-Nebenläufigkeit auf dem nativen Server zu begrenzen, dimensionieren Sie die Slots jedes SDK-Workers und die Anzahl der Worker. [Task-Warteschlangenzulassung](/docs/polyglot/task-queue-admission) beschreibt die Steuerungen von PHP 2.x.
 
@@ -294,7 +296,9 @@ 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.
+Native 3.9.2 wendet die bestehende Grenze von 255 Unicode-Codepunkten auf Signal- und Update-Command-Keys durchgehend bei der Annahme an. Ein mehrbyteiges `request_id` mit 255 Zeichen wird akzeptiert, 256 Zeichen werden ohne Annahme abgewiesen. Das korrigiert die [UTF-8-Byte-Ablehnung aus 3.9.1](https://github.com/durable-workflow/server/issues/934#issuecomment-6853943056). Verwenden Sie das `request_id` im Body als Retry-Key; der HTTP-Header `X-Request-Id` ist kein Command-Key.
+
+Neue Signal-Belege mit Schlüssel und Belege akzeptierter Updates in 3.9.2 geben das literale `request_id` mit `retained:false` und `intent_verified:true` zurück. Aufbewahrte Belege geben den Schlüssel mit `retained:true` zurück und behalten ursprüngliche Command-, Run- und Update-Identitäten. Moderner Intent-Nachweis meldet `intent_verified:true`, kompatibles Legacy-Readback ohne Intent meldet `intent_verified:false`. Belege ohne Schlüssel und Bridge-Belege bleiben unverändert. Die [veröffentlichte Korrektur](https://github.com/durable-workflow/server/releases/tag/3.9.2#command-keys-and-receipts) qualifiziert nicht alle installierten Client-Kohorten unter [gemeinsamem #216](https://github.com/durable-workflow/.github/issues/216); frühere 3.9.1-Fehlschläge müssen auf dem exakten korrigierten Tupel wiederholt werden.
 
 Die aktuell konfigurierten Werte werden unter `limits` in der Antwort von
 `GET /api/cluster/info` veröffentlicht. Clients können sie dadurch zur Laufzeit

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

@@ -135,7 +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).
+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.
 
 ### 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": "04e84a3aa2b2fb57c4108468c85f862156249d67c7b96c4ad159faccd8661afe",
+  "deployment.md": "dbc8ff149cea02d1db474e4decd83ee12692a59087d86e8fcc7d7655206961e9",
   "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": "2cc511074e6d0ce8ababa0ccd6acbdaa7df3bf5d8c67ae5ef2fa07d75a05d2e7",
   "polyglot/server-api-reference.md": "8bac825f11f7aa3f2a335cf3d1dcdc951219f11d6702e9fe3502d3803fd1e2a5",
-  "polyglot/server-config-reference.md": "e7dc68015e9c1e43b102aa657c0dd2bc12487ef344cb10bdb2379c297114431f",
+  "polyglot/server-config-reference.md": "88f440db04a4636c1c2f88b3613c45b5b0cdf46aa27cf64c800f56feac59dfa5",
   "polyglot/server-role-topology.md": "3d048f0c6b5f179399622508f51e67fff8aa5a6d5b2492533fc720eeec2c27f2",
-  "polyglot/server.md": "55d5962ff5da8e29fbe0d568635c4d88ce539e39fdddce292df04b95b3561546",
+  "polyglot/server.md": "a2404c130fdc8611eff4b8844729225b95292eafd4206145078c3fe270d2b30c",
   "polyglot/service-operations.md": "a2ee46ac8d2e4f18aed4e3cb47a4f0b36f51ccc67f1e841efb99f0297391cf27",
   "polyglot/task-matching-dispatch.md": "9c8ffbbee16b5da48e7882721d7ba8eac209a374a6ca766d93d2b17e825b203d",
   "polyglot/task-queue-admission.md": "efcf934876a27c153dd3ecd1a995e7c08b37452c79dfcbba1ae7fa0a8cbad327",