Различия

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

--- sharixopen:knowledge:scenarios:service_request_accepted [2026/10/28 21:01] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_accepted [2026/10/31 12:14] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 15: / Строка 15: @@
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 21: / Строка 27: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "ACCEPTED",
+                "audience_integrator",
-                "preparation",
+                "audience_support",
-                "payment",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "topic_orders_assignment",
+                "service_request",
+                "ticket_accepted",
+                "order_preparation",
+                "payment_state",
+                "bpmn",
+                "order",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 201: / Строка 221: @@
                 "backend": "92ec231d2d5d2b5fe9a34600975905123377c0dfa1a0e767f4b0eef182f3b418"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "integrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/lifecycle",
+                "orders/payments",
+                "orders/assignment"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_integrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "topic_orders_assignment",
+                "service_request",
+                "ticket_accepted",
+                "order_preparation",
+                "payment_state",
+                "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": 25,
+            "original_source_evidence_recheck": "После git fetch все исходные SHA-256 совпали; source_evidence содержит текущие проверенные commits",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_service_request_accepted.py",
+                    "generated_handlers/open_service_request_accepted.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "8fc5880a79c6052daeaa034c541afccddbc16c189060978b5de0857565e47ea8",
+    "content_sha256": "cc9b331f25fb52f74fb22b829fd224b6f96b801c6dd3e4f7eb4e5a9ca2ec5d86",
     "schema": 1
 }
@@ Строка 210: / Строка 288: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_accepted'', тип ''SERVICE_REQUEST'' (2), статус ''ACCEPTED''. Опубликованный Python на 28.10.2026 побайтово совпадает с результатом канонической генерации Blockly workspace. Фактически выбранную server version и настройки проверяют отдельно.
+**Назначение:** [[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#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#finalizacija_oplaty|Заказы → Финализация оплаты]] · [[sharixopen:knowledge:classification:topics#naznachenie|Заказы → Назначение]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_accepted'', тип ''SERVICE_REQUEST'' (2), статус ''ACCEPTED''. 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly. Сам обработчик и его внешние действия при анализе не запускались. Выбранная версия, настройки и работоспособность конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-Исполнитель уже назначен и принял заказ. Handler сопровождает переход ACCEPTED→PRE_START: ждёт доступности подготовки, предлагает её подтвердить либо делает обязательную попытку по контрольной дате. Любая ветка использует канонический ''prepare-accepted'' и сохраняет backend-ограничения исполнителя, одновременных заказов и оплаты.
+Вход — заказ с назначенным исполнителем, который уже принял его. Handler сопровождает ACCEPTED → PRE_START:
+  * ждёт доступности подготовки;
+  * при ручном режиме предлагает подтвердить подготовку;
+  * по контрольной дате предпринимает обязательную попытку подготовки;
+  * во всех ветвях сохраняет проверки исполнителя, одновременных заказов и оплаты через prepare-accepted.
 Отдельно обрабатывается необходимость привязки карты **клиентом сервиса**. Ожидание клиентского платёжного действия не приравнивается к отказу исполнителя. BPMN описательные, ''isExecutable=false''; runtime исполняет выбранный проверенный Python из Blockly, а не схему Wiki.
@@ Строка 494: / Строка 585: @@
 ==== 1. Привязка карты имеет приоритет ====
-Флаг ''payment_requires_card_binding'' формируется из платёжного ''customer_action'': required=true, code=bind_card, target=client. При нём handler **сразу**, до проверок времени и auto-режима, вызывает prepare-accepted. Успех/stale освобождает очередь, неуспех ведёт к ACCEPTED_RECHECK.
+Признак привязки карты строится по customer_action платёжного состояния:
+  * required=true;
+  * code=bind_card;
+  * target=client.
+При payment_requires_card_binding handler сразу вызывает prepare-accepted, до проверки времени и auto-режима. Успех/stale освобождает очередь; доменный неуспех ведёт к SERVICE_REQUEST_ACCEPTED_RECHECK_SECONDS.
 В этой ветке нет проверки порога неуспехов и автоматического decline-provider, хотя wrapper prepare учитывает доменные неуспехи в общем счётчике. Нельзя описывать ожидание карты как «после нескольких попыток исполнитель автоматически откажется». Вызов проходит реальный payment hook: сам диагностический флаг не является отдельным запретом перехода или разрешением его обойти. Если hook уже допускает подготовку, вызов может завершиться раньше обычной временной ветки.
@@ Строка 501: / Строка 598: @@
 ==== 2. Обязательная попытка по pre_start_at ====
-Если особой card-ветки нет и ''pre_start_at'' наступил, handler пробует prepare независимо от AUTO_PRE_START и наличия ответа. Успех/stale освобождает очередь. Доменный неуспех проверяет собственный счётчик prepare; при достижении порога предпринимается decline-provider, иначе/при его неуспехе — RECHECK.
+Когда особой card-ветки нет и pre_start_at наступил:
+  - Попробовать prepare независимо от AUTO_PRE_START и ответа исполнителя.
+  - При успехе/stale закончить обработку текущей стадии.
+  - При доменном неуспехе проверить отдельный счётчик prepare.
+  - При достижении порога попробовать decline-provider; если порог не достигнут или decline неуспешен — назначить RECHECK.
+Обязательна попытка, а не гарантированный PRE_START. Платёжное ограничение или конфликт активных заказов может сохранить ACCEPTED.
 «Обязательная» означает обязательную **попытку**, а не гарантированный PRE_START: конфликт активных заказов или платёжное условие могут оставить ACCEPTED. Если дата отсутствует/некорректна, timing helper не считает её наступившей; это повод проверить исходные даты, а не ждать гарантированного автоматического перехода.
@@ Строка 508: / Строка 612: @@
 До pre_start_at включённый ''SERVICE_REQUEST_ACCEPTED_AUTO_PRE_START'' пропускает приглашение исполнителю и ждёт RECHECK. Выключенный auto-режим начинает ручной раунд после ''prepare_available_at''. Раньше этого окна тоже только RECHECK.
-В ручном раунде winner/no_winner проверяются до отправки; затем — исчерпание попыток. Если терминального решения нет, отправляется попытка, разбираются queued web intents и winner/no_winner проверяются ещё раз. Winner вызывает prepare, no_winner/предусмотренное исчерпание — decline. Иной исход ждёт NOTIFICATION_INTERVAL.
+Порядок ручного раунда:
+  - Проверить уже сохранённый winner/no_winner.
+  - Проверить предусмотренное исчерпание попыток.
+  - Если терминального решения нет — отправить попытку и разобрать queued web intents.
+  - Снова проверить winner/no_winner.
+  - Winner ведёт к prepare, no_winner и предусмотренное исчерпание — к decline; иной исход ждёт интервала уведомлений.
 ===== Исполнитель, сообщение и срок ответа (BPMN) =====
@@ Строка 786: / Строка 896: @@
 </sharix-bpmn>
-Получатель — текущий provider с JID из context. Сообщение ''order.action.required'' предлагает prepare/decline, передаёт available_from=prepare_available_at, due_at=pre_start_at, ''popup_policy=online_only''. Это описание предлагаемого действия; показ интерфейса и прочтение человеком не гарантируются успешным XMPP-send.
+Приглашение order.action.required адресуется текущему provider и содержит:
+  * prepare — подтвердить подготовку;
+  * decline — отказаться;
+  * available_from=prepare_available_at;
+  * due_at=pre_start_at;
+  * popup_policy=online_only.
+Успешный XMPP-send не подтверждает показ интерфейса и прочтение человеком.
 Используются ''SERVICE_REQUEST_ACCEPTED_ROUND_STRATEGY'', ''...DELIVERY_POLICY'', число попыток, интервал и окно ответа. Общий срок раунда от создания: ''(attempts−1) × notification_interval + response_window''. Пустой JID/список получателей не даёт успешного раунда; handler остаётся на повторе. Попытка учитывается до I/O, неуспешный send также может расходовать лимит.
@@ Строка 989: / Строка 1107: @@
 </sharix-bpmn>
-Scoped ''prepare-accepted'' требует capability ''order.prepare_accepted''. Runtime передаёт expected provider id, ''SERVICE_REQUEST_SINGLE_ACTIVE_ORDER'', ''SERVICE_REQUEST_OFFLINE_ON_PRE_START'' и допустимые location-поля из ответа победителя, если они есть. Backend под lock сверяет текущее назначение и ACCEPTED, корректного provider/user и hard eligibility; затем применяет concurrency policy и ''handle_before_order_pre_start'' выбранного платёжного backend через facade.
+Backend prepare-accepted:
+  - Проверяет capability order.prepare_accepted и scope.
+  - Под lock сверяет ACCEPTED, текущее назначение, provider/user и hard eligibility.
+  - Применяет concurrency policy.
+  - Вызывает handle_before_order_pre_start выбранного платёжного backend через facade.
+  - При допуске сохраняет PRE_START.
+Runtime передаёт expected_provider_id, SERVICE_REQUEST_SINGLE_ACTIVE_ORDER, SERVICE_REQUEST_OFFLINE_ON_PRE_START и допустимые location-поля победителя, если они есть.
 При допуске сохраняется PRE_START. По настройке предложения исполнителя переводятся offline, запускается предусмотренный prediction hook. Доменный отказ возвращает неуспех без обещания перехода. Даты prepare_available_at/pre_start_at этот narrow action отдельно не проверяет: время определяет текущий Python flow, а backend защищает бизнес-ограничения.
@@ Строка 1010: / Строка 1136: @@
 Счётчик доменных неуспехов prepare отличается от счётчика send-попыток, хотя использует тот же порог NOTIFICATION_ATTEMPTS. Исключение транспорта/401/403/5xx не является автоматически зарегистрированным отрицательным ответом исполнителя: оно идёт в ''processing_error'' и общий ''DEFERRED_TICKET_RECHECK_SECONDS''.
-Проверяйте последовательно текущий статус/provider, card-флаг и реальное payment state, обе даты, auto-настройку, outcome раунда, результат narrow action и сохранённый Ticket. Доменный отказ, send failure, молчание человека и ожидание карты — разные причины. Локальный ''provider_preparation'' сам по себе не доказывает отправки приглашения.
+При диагностике проверить по порядку:
+  - Актуальные статус и provider.
+  - Card-флаг и реальное платёжное состояние.
+  - prepare_available_at и pre_start_at.
+  - Auto-настройку и outcome раунда.
+  - Ответ prepare-accepted/decline-provider и фактически сохранённый Ticket.
+Доменный отказ, send failure, молчание человека и ожидание карты — разные причины. Локальный provider_preparation не доказывает отправки приглашения.
 Round registry, ответы, send- и action-счётчики живут в памяти процесса и не восстанавливают старый round id после рестарта. Defer освобождает worker; backend event может сделать Ticket ready раньше. После commit перехода ''ticket.changed'' будит следующего владельца, ''ticket.moved'' очищает прежнего; periodic reconciliation по ''INTERVAL_TIME_BD_REQ'' восстанавливает состав при потере событий.