Различия

Показаны различия между двумя версиями страницы.

--- sharixopen:knowledge:scenarios:service_request_assigned [2026/10/28 20:44] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_assigned [2026/10/31 13:21] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 15: / Строка 15: @@
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers",
+            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 21: / Строка 28: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "ASSIGNED",
+                "audience_integrator",
-                "provider round",
+                "audience_support",
-                "BPMN"
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_assignment",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "service_request",
+                "ticket_assigned",
+                "provider_offer",
+                "order_preparation",
+                "order_round",
+                "bpmn",
+                "order",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 194: / Строка 217: @@
                 "actions": "3af9725b64b426743f4bb1471a234b5760f7f3f688902e47e27a972b2bde6efe"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "integrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/assignment",
+                "orders/lifecycle",
+                "orders/payments"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_integrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_assignment",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "service_request",
+                "ticket_assigned",
+                "provider_offer",
+                "order_preparation",
+                "order_round",
+                "bpmn",
+                "order",
+                "ticket",
+                "blockly",
+                "generated_python"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "Конкретизация действий, условий, результатов и диагностики; перечисления; исходные BPMN сохранены",
+            "current_source_records_verified": 24,
+            "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_service_request_assigned.py",
+                    "generated_handlers/open_service_request_assigned.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "b62dac8040fbe211b65320bc18c0f1f900b4154d4fe3ea5be9f8c27ea8b46b62",
+    "content_sha256": "eeedeead03d64279d968e39169b6f198474be1b59f360587e0eac1a97d4450cb",
     "schema": 1
 }
@@ Строка 203: / Строка 285: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_assigned'', тип ''SERVICE_REQUEST'' (2), рабочий статус ''ASSIGNED'' (212). Опубликованный Python на 28.10.2026 побайтово совпадает с каноническим renderer Blockly workspace. Выбранная версия/настройки конкретного сервера проверяются отдельно.
+**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#integrator|Интегратор]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#naznachenie|Заказы → Назначение]] · [[sharixopen:knowledge:classification:topics#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#finalizacija_oplaty|Заказы → Финализация оплаты]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_assigned'', тип ''SERVICE_REQUEST'' (2), рабочий статус ''ASSIGNED'' (212). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия, настройки и доступность подключений конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-Handler сопровождает заказ с уже назначенным исполнителем. При включённом ''SERVICE_REQUEST_ASSIGNED_AUTO_ACCEPT'' он пропускает раунд человеческого подтверждения и вызывает каноническое принятие. При выключенном — ждёт исхода раунда назначенного provider, затем принимает назначение либо фиксирует отказ. Он не выбирает победителя среди новых кандидатов и не заменяет backend-проверки текущего исполнителя.
+Обработчик получает заказ с уже назначенным исполнителем:
+  * **SERVICE_REQUEST_ASSIGNED_AUTO_ACCEPT включён:** пропустить человеческий раунд и вызвать каноническое принятие.
+  * **Выключен:** дождаться исхода раунда текущего provider и применить принятие либо отказ.
+Новый кандидат здесь не выбирается. Backend заново проверяет текущего исполнителя.
+Составное accept_prepare:
+  - Сохранить ASSIGNED → ACCEPTED.
+  - Попробовать перейти в PRE_START через каноническую подготовку.
+  - Если подготовка заблокирована ожидаемым доменным условием — сохранить принятие и вернуть success с prepared=false.
-Принятие через этот handler использует составное действие ''accept_prepare'': ASSIGNED→ACCEPTED, затем попытка PRE_START. Доменный отказ подготовки, например платёжное условие или конфликт активных заказов, **не отменяет уже выполненное принятие**: ответ может быть success с ''prepared=false'', а Ticket остаётся ACCEPTED. Это отличается от обещания «любой положительный ответ уже означает PRE_START».
+Платёжное ограничение или конфликт активных заказов не отменяет уже выполненное принятие. Положительный ответ может означать ACCEPTED, а не PRE_START.
 BPMN имеют ''isExecutable=false''. Wiki не исполняет обработчик; runtime запускает выбранный проверенный Python из Blockly. Раунды и счётчики находятся в памяти процесса, не в Ticket.json.
@@ Строка 559: / Строка 660: @@
 Сначала записывается ''provider_confirmation_round'', в том числе перед auto-ветвью: сама эта причина не доказывает отправки человеку. В auto-режиме сразу вызывается ''accept-assigned''.
-В ручном режиме ''winner'' и ''no_winner'' проверяются до отправки. Если исхода ещё нет, проверяется исчерпание попыток, затем отправляется попытка раунда и разбираются web intents, пришедшие до его создания. После отправки ''winner''/''no_winner'' проверяются повторно в том же проходе. Иной исход ведёт к defer по ''SERVICE_REQUEST_ASSIGNED_NOTIFICATION_INTERVAL_SECONDS''.
+Ручной режим в одном проходе:
+  - Проверить существующий winner/no_winner.
+  - Если результата нет — проверить исчерпание попыток.
+  - Отправить попытку и разобрать web intents, пришедшие до создания раунда.
+  - Снова проверить winner/no_winner в том же проходе.
+  - При ином исходе назначить SERVICE_REQUEST_ASSIGNED_NOTIFICATION_INTERVAL_SECONDS.
   * ''winner'' → попытка принятия назначения.
@@ Строка 566: / Строка 673: @@
   * Успех/stale канонического действия исключает Ticket из текущей очереди. Обработанный отрицательный decline остаётся на обычном повторе; исключение API идёт в общий ''processing_error''.
-Счётчик неуспехов accept и число попыток рассылки различны, хотя порог действия берётся из ''SERVICE_REQUEST_ASSIGNED_NOTIFICATION_ATTEMPTS''. Успех/stale сбрасывает неуспехи действия. Ошибка транспорта/авторизации, прервавшая API-вызов исключением, не является автоматически зарегистрированным отказом исполнителя.
+Учитываются два разных счётчика:
+  * **Send-попытки:** сколько приглашений пытались отправить.
+  * **Доменные неуспехи accept:** сколько обработанных ответов действия не привели к успеху; успех/stale сбрасывает этот счётчик.
+Для порога действия используется SERVICE_REQUEST_ASSIGNED_NOTIFICATION_ATTEMPTS. Исключение транспорта или авторизации не является отрицательным ответом исполнителя.
 ===== Исполнитель, сообщение, ответ и таймер (BPMN) =====
@@ Строка 849: / Строка 961: @@
 ==== Стратегия определяет исход тайм-аута ====
-Встроенная ''single_confirmation'' допускает ровно одного получателя: accept даёт winner, decline — no_winner, истечение срока — no_winner. Встроенная ''first_accept'' на положительный ответ даёт winner, на все отрицательные — no_winner, но унаследованный timeout даёт ''timed_out''.
+У встроенных стратегий различается тайм-аут:
+  * **single_confirmation:** один получатель; accept → winner, decline → no_winner, timeout → no_winner.
+  * **first_accept:** положительный ответ → winner, все отрицательные → no_winner, timeout → timed_out.
+Timed_out не равен no_winner в этом Python. Закрытый раунд не считается активным при проверке исчерпания, а следующий send может создать новый раунд.
 ''timed_out'' не приравнивается этим Python к no_winner. Закрытый раунд не считается активным при проверке исчерпания попыток; при следующем send может создаться новый раунд. Поэтому нельзя обещать одинаковое автоматическое отклонение при любом выборе strategy. Фактическую настройку нужно сверять отдельно; схема сохраняет ветку «иной исход».
@@ Строка 1023: / Строка 1140: @@
 </sharix-bpmn>
-''accept-assigned'' требует ''order.accept_assigned'' и текущий Ticket scope. Runtime передаёт expected provider id из свежего context; backend блокирует актуальный заказ, сверяет назначенного provider и его eligibility, сохраняет ACCEPTED и пробует PRE_START.
+Backend accept-assigned:
+  - Проверить order.accept_assigned и текущий Ticket scope.
+  - Под lock сверить актуальное назначение и expected provider id из context.
+  - Проверить eligibility исполнителя.
+  - Сохранить ACCEPTED и попробовать PRE_START.
+Согласие, принятое раундом, не заменяет эти повторные backend-проверки.
 В вызове от имени handler нет отдельного ожидания ''prepare_available_at''/''pre_start_at'' и ASAP не является обязательным условием составного принятия. Подготовка всё равно проходит канонические ограничения одновременных заказов и платёжный hook. При успехе сохраняется PRE_START, применяются предусмотренные offline/prediction hooks. При ожидаемом доменном блокировании подготовки ответ фиксирует успешное принятие, ''prepared=false'' и ACCEPTED; последующий ACCEPTED handler продолжает процесс. Неожиданное исключение транзакции — другой случай, его нельзя приравнивать к такому успешному частичному ответу.
@@ Строка 1043: / Строка 1167: @@
 Реальные значения не предполагаются. Defer освобождает worker; внешнее событие может сделать Ticket готовым раньше обычного срока. Раунд, ответы, рассылка и счётчик доменных неуспехов — процессная память. После рестарта нужно различать сохранённое назначение/статус и новый локальный раунд.
-При диагностике сначала проверьте текущего provider, его JID, auto-настройку, strategy и round outcome. Затем разделите попытку send, фактический ответ, решение стратегии, результат accept/decline и окончательную стадию. ACCEPTED с ''prepared=false'' может означать штатное сохранённое принятие с необходимым платёжным действием/устранением конфликта, а не потерянный ответ исполнителя.
+Порядок диагностики:
+  - Прочитать актуального provider и проверить его JID.
+  - Сверить auto-настройку, strategy и round outcome.
+  - Разделить попытку send, фактический ответ человека и решение стратегии.
+  - Прочитать результат accept/decline и фактическую конечную стадию.
+  - При ACCEPTED с prepared=false разобрать платёжное условие либо конфликт подготовки.
+Частично успешное принятие не следует автоматически считать потерянным ответом исполнителя.
 ===== Проверенные источники =====