Различия

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

--- sharixopen:knowledge:scenarios:service_request_process [2026/10/28 21:16] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_process [2026/10/31 14:26] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 13: / Строка 13: @@
             "ShariXKnowledgeServiceRequestTemplateBPMN",
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
-            "ShariXKnowledgeScenarios"
+            "ShariXKnowledgeScenarios",
+            "ShariXKnowledgeOpenKnowledgeModulesWebservicerunning"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers",
+            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 20: / Строка 28: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce, webservice_running",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "PROCESS",
+                "audience_integrator",
-                "execution stages",
+                "audience_support",
-                "subscription",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_execution",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "service_request",
+                "ticket_process",
+                "order_round",
+                "payment_state",
+                "completion_gate",
+                "blocking_stage",
+                "subscription_access_order",
+                "bpmn",
+                "order",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 246: / Строка 271: @@
                 "Active finish-only round captures trusted web force_majeure and may reject action_mismatch instead of immediate queue."
             ]
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "integrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/execution",
+                "orders/lifecycle",
+                "orders/payments"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_integrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_execution",
+                "topic_orders_lifecycle",
+                "topic_orders_payments",
+                "service_request",
+                "ticket_process",
+                "order_round",
+                "payment_state",
+                "completion_gate",
+                "blocking_stage",
+                "subscription_access_order",
+                "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": 32,
+            "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_service_request_process.py",
+                    "generated_handlers/open_service_request_process.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "bd883948c1f0198334e12031b806cae59f219c661d61f6d24a2407f2185041a3",
+    "content_sha256": "bb247be14870f7ee5d92636e6256e9c6bfd5afa6dc20c88784eaf7a7ce49f8e8",
     "schema": 1
 }
@@ Строка 255: / Строка 341: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_process'', тип ''SERVICE_REQUEST'' (2), статус ''PROCESS''. Проверено 29.10.2026: опубликованный Python побайтово совпадает с результатом канонической генерации 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#ispolnenie|Заказы → Исполнение]] · [[sharixopen:knowledge:classification:topics#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#finalizacija_oplaty|Заказы → Финализация оплаты]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_process'', тип ''SERVICE_REQUEST'' (2), статус ''PROCESS''. 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия и работающая установка проверяются отдельно.
 ===== Назначение и границы =====
-Handler сопровождает выполняемый заказ до DONE, учитывая внешний completion gate этапов. До обычного завершения он проверяет истечение заказа доступа подписки и принимает подходящий queued пользовательский intent. Заказ подписки, обычный заказ, обязательный этап, платёжная финализация и закрытие Ticket — разные части процесса.
+Порядок обработки выполняемого заказа:
+  - Проверить истечение системного заказа доступа подписки.
+  - Обработать одно подходящее queued пользовательское намерение.
+  - Загрузить context и проверить внешний completion gate этапов.
+  - При допуске проверить planned_finish и выполнить автоматическое завершение либо раунд finish.
+Обычная работа, подписка, блокирующий этап, платёжная финализация и CLOSED — разные части процесса.
 BPMN описательные, ''isExecutable=false''. Blockly фиксирует порядок вызовов и решений; исполняется сгенерированный Python. Модели Stage и их пользовательские действия принадлежат ''webservice_running'', Orders и канонические переходы — ''dbsynce''. Нейтральный integration port связывает их, не превращая Blockly в исполнитель внешних этапов.
@@ Строка 746: / Строка 847: @@
 </sharix-bpmn>
-''order.execution.completion_gate'' читает нейтральный порт. В текущем ''webservice_running'' адаптер регистрируется в Apps.ready. Его completion_gate ищет Stage этого заказа с **blocks_order_completion=true и status=PENDING**, включая записи вне обычного workspace. Список blocking_stages и причина возвращаются backend и handler.
+Проверка order.execution.completion_gate читает нейтральный порт. Адаптер webservice_running регистрируется в Apps.ready и ищет Stage:
+  * этого заказа;
+  * с blocks_order_completion=true;
+  * со status=PENDING.
+Проверяются также записи вне обычного workspace. Backend и handler получают blocking_stages и причину запрета.
 Уполномоченный участник выполняет работу и отмечает checklist/этап через модуль исполнения. ''complete_stage'' проверяет видимость, policy права завершать и отсутствие незавершённых обязательных checklist items; только потом сохраняет Stage COMPLETED. Handler сам не отмечает эти этапы выполненными. Снятие блокировки тоже отдельное разрешённое действие policy, не способ для handler обойти невыполненную работу.
@@ Строка 752: / Строка 859: @@
 Очередной проход перечитывает gate. Даже если до приглашения он разрешал завершение, **канонический finish повторно проверяет gate под lock**: промежуточный снимок не даёт права закрыть вновь заблокированный заказ.
-Если runtime adapter не зарегистрирован, метода нет, он вернул None либо порт получил неподходящий тип результата, публичный порт использует default allowed=true. Исключение вызванного метода автоматически этим портом не превращается в разрешение. Поэтому «gate разрешил» без проверки регистрации не доказывает, что реальные Stage были проверены. Нельзя выдавать отсутствие модуля/регистрации за завершённость всех этапов.
+Публичный порт возвращает default allowed=true, если:
+  * runtime adapter не зарегистрирован;
+  * у adapter нет вызываемого completion_gate;
+  * метод вернул None;
+  * результат имеет неподходящий тип.
+Исключение вызванного метода само по себе не становится разрешением. Поэтому allowed=true без проверки регистрации не доказывает, что реальные Stage проверены.
 ===== Исполнитель, finish и интервал повторов (BPMN) =====
@@ Строка 978: / Строка 1092: @@
 </sharix-bpmn>
-Раунд адресует одного текущего provider по JID. Сообщение ''order.action.required'' предлагает finish без альтернативного действия, popup_policy=active_order и due_at=planned_finish. Срок ''expires_at'' для PROCESS раунда не устанавливается. due_at — плановый ориентир, не TTL допустимости ответа.
+Приглашение order.action.required адресуется текущему provider и содержит:
+  * finish без альтернативного действия;
+  * popup_policy=active_order;
+  * due_at=planned_finish.
+Expires_at для PROCESS-раунда не устанавливается. Плановая дата не является TTL ответа.
 Используются ''SERVICE_REQUEST_PROCESS_ROUND_STRATEGY'', ''...DELIVERY_POLICY'', ''...NOTIFICATION_ATTEMPTS'' (минимум 1) и ''...NOTIFICATION_INTERVAL_SECONDS''. Таймер BPMN обозначает следующий проход/отправку. Достигнутый лимит активного раунда приводит к reset и повтору, не к безусловному завершению заказа без исполнителя. Попытка учитывается до I/O; send failure не равен человеческому отказу.
@@ Строка 992: / Строка 1112: @@
 Narrow ''finish-process'' требует ''order.finish_process'', текущий scope, PROCESS и provider. Под lock он повторяет completion gate, разрешает time_mode planned/actual и делает канонический DONE. Planned берёт первое доступное ''time_finish_predicted'', затем ''time_finish_placed''; actual — backend now. Сам action не проверяет, наступила ли плановая дата: её проверяет Python.
-При успехе пустые ''time_finish_real'' и ''location_finish_real'' заполняются через effective time/location resolver, уже сохранённые значения не перезаписываются. Рассчитывается real_price. Actual wrapper может передать допустимые location-поля победителя; planned wrapper не передаёт их. Текущий wrapper не посылает expected_provider_id, хотя backend умеет сверять его при наличии.
+После успешного finish:
+  * пустое time_finish_real заполняется effective time;
+  * пустая location_finish_real заполняется через location resolver;
+  * существующие фактические значения сохраняются;
+  * рассчитывается real_price.
+Actual wrapper может передать допустимые location-поля победителя, planned wrapper их не передаёт. Текущий wrapper не отправляет expected_provider_id, хотя backend поддерживает проверку этого параметра.
 После успешного DONE вызывается ''handle_after_order_done'' выбранного платёжного backend и предпринимается создание следующего повторного заказа. Платёжный hook может добавить сообщение «требуется внимание» без отмены success самого finish. Ошибка создания повторного заказа логируется и добавляет предупреждение, не объявляет предыдущую работу незавершённой. Неожиданное исключение и обработанный доменный результат различаются; после сетевой неопределённости сначала перечитывают фактический статус.
@@ Строка 1125: / Строка 1252: @@
 ''expire-subscription'' требует ''order.expire_subscription''. Он применяется именно к системному тарифу доступа, связанному через category.subscription_service_id, а не ко всем заказам, оплачиваемым/покрытым подпиской. Для обычного заказа возвращается applicable=false, expired=false. Для ещё не наступившего срока или отсутствующего time_finish_placed — expired=false.
-При наступившем сроке backend сохраняет time_finish_real=time_finish_placed и real_price=predicted_price, переводит PROCESS→DONE, затем вызывает ensure_order_can_be_closed. Если платёжный gate разрешает, выполняется CLOSED и возвращается expired=true. Это путь без подтверждения provider и без обычного round finish.
+Истечение заказа доступа подписки:
+  - Сохранить time_finish_real=time_finish_placed и real_price=predicted_price.
+  - Перевести PROCESS → DONE.
+  - Вызвать ensure_order_can_be_closed.
+  - Если платёжный gate разрешил — выполнить CLOSED и вернуть expired=true.
+Это отдельный путь без подтверждения provider и обычного finish-раунда. Если оплата блокирует закрытие, уже сохранённый DONE требует отдельной проверки.
 Если payment gate блокирует уже после DONE, возвращается неуспех, но DONE может быть сохранён. ''expired=false''/его отсутствие не доказывает, что все изменения отменены. PROCESS scope следующего запроса может стать stale, а DONE handler продолжит платёжную финализацию. Это отличается от гарантии одной неделимой операции «либо сразу CLOSED, либо PROCESS».
@@ Строка 1140: / Строка 1274: @@
 Defer освобождает worker; ответ/событие может сделать Ticket ready раньше. 404 scope очищает устаревшую локальную запись, auth/transport/5xx не считаются отказом исполнителя и идут в processing_error. После commit ''ticket.changed''/''ticket.moved'' передают владение, periodic reconciliation компенсирует потерю события.
-При диагностике разделяйте подписку, внешний blocking Stage, плановую дату, активный раунд, полученный ответ, сохранённый DONE и платёжную финализацию. Для этапов проверяйте их текущие flags/status и регистрацию runtime adapter. Для внешнего сообщения о проблеме — маршрут через активный finish round. Не запускайте повторный finish только из-за предупреждения об оплате, пока не перечитан текущий Orders/Ticket.
+Порядок диагностики:
+  - Определить, обычный ли это заказ или системный доступ подписки.
+  - Проверить blocking Stage, их flags/status и регистрацию адаптера.
+  - Сверить planned_finish, активный раунд и маршрут ответа/intent.
+  - Прочитать результат канонического finish.
+  - Отдельно проверить сохранённый DONE, платёжную финализацию и CLOSED.
+Предупреждение об оплате не является основанием вслепую повторять finish; сначала перечитать Orders/Ticket.
 ===== Проверенные источники =====