Различия

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

--- sharixopen:knowledge:scenarios:service_request_prestart [2026/10/28 21:10] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_prestart [2026/10/31 12:14] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 14: / Строка 14: @@
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 20: / Строка 26: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "PRE_START",
+                "audience_integrator",
-                "PROCESS",
+                "audience_support",
-                "BPMN"
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_execution",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_pre_start",
+                "ticket_process",
+                "bpmn",
+                "order",
+                "ticket",
+                "order_intent",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 202: / Строка 223: @@
                 "Active PRE_START round accepts start only; trusted web force_majeure is routed to that round and may get action_mismatch instead of entering immediate queue."
             ]
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "integrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/lifecycle",
+                "orders/execution",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_integrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_execution",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_pre_start",
+                "ticket_process",
+                "bpmn",
+                "order",
+                "ticket",
+                "order_intent",
+                "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_prestart.py",
+                    "generated_handlers/open_service_request_prestart.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "7afb8c8ce14fe5122e36fa238045b316a140cd5571da6c355287f55572a88369",
+    "content_sha256": "d0b67b8bfa0f1004820da2b76a59fb56d2cc1800b98a7e951b77a06e9afa77a1",
     "schema": 1
 }
@@ Строка 211: / Строка 290: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_prestart'', тип ''SERVICE_REQUEST'' (2), статус ''PRE_START''. Проверено 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#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#ispolnenie|Заказы → Исполнение]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_prestart'', тип ''SERVICE_REQUEST'' (2), статус ''PRE_START''. 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly. Сам обработчик и его внешние действия при анализе не запускались. Выбранная версия, настройки и работоспособность конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-После подготовки handler сопровождает начало выполнения **PRE_START→PROCESS**. Он принимает отдельные queued web intents раньше временной ветки, а после планового начала либо стартует автоматически, либо приглашает назначенного исполнителя подтвердить start. Отсутствие ответа не превращается этим Python в автоматический отказ или форс-мажор.
+Handler сопровождает переход PRE_START → PROCESS:
+  - Сначала попробовать разрешённое пользовательское намерение из локальной очереди.
+  - Если проход продолжается — получить актуальный scoped context заказа.
+  - Дождаться planned_start для обычной временной ветви.
+  - После даты — автоматически запросить начало либо предложить назначенному исполнителю подтвердить start.
+Отсутствие ответа само по себе не превращается в автоматический отказ или форс-мажор.
 Схемы BPMN описательные, ''isExecutable=false''. Runtime исполняет проверенный Python из Blockly; Wiki не является исполняемым process engine. Человеческое подтверждение, доставка сообщения и сохранённый PROCESS — разные события.
@@ Строка 488: / Строка 582: @@
 </sharix-bpmn>
-При своём статусе сначала обрабатывается **один подходящий queued intent**: start, force_majeure, decline или refuse. Успех/stale заканчивает проход. Обработанный неуспех позволяет продолжить обычную логику; исключение идёт в общий processing_error. Наличие intent в этой очереди зависит от маршрутизации до processing, описанной ниже.
+До временной ветви извлекается одно подходящее queued intent:
+  * start;
+  * force_majeure;
+  * decline;
+  * refuse.
+Успех или stale заканчивает проход; обработанный доменный неуспех позволяет продолжить обычную логику. Исключение идёт в processing_error. Наличие intent в этой очереди зависит от маршрутизации, описанной ниже.
 Затем загружается scoped order context, устанавливается локальная причина ''provider_start'' и проверяется ''planned_start''. До этой даты — RECHECK. При отсутствии/некорректной дате helper не считает срок наступившим; обычная auto/round-ветка не стартует, но ранее обработанный пользовательский start — отдельный путь.
@@ Строка 726: / Строка 827: @@
 </sharix-bpmn>
-Адресат — один текущий provider с JID из backend context. Сообщение ''order.action.required'' содержит start, ''popup_policy=active_order'', due_at=planned_start. Альтернативное действие в этом приглашении не задаётся. Значение due_at здесь информирует о плановой дате; **expires_at для PRE_START раунда не задаётся**.
+Приглашение адресуется текущему provider с JID из backend context. Сообщение order.action.required содержит:
+  * действие start;
+  * popup_policy=active_order;
+  * due_at=planned_start.
+Альтернативное действие и expires_at для PRE_START-раунда не задаются. Due_at сообщает плановую дату, а не создаёт срок истечения ответа.
 Используются ''SERVICE_REQUEST_PRE_START_ROUND_STRATEGY'', ''...DELIVERY_POLICY'', ''...NOTIFICATION_ATTEMPTS'' и ''...NOTIFICATION_INTERVAL_SECONDS''. Число попыток может быть 0: это не запрет приглашений, а отсутствие конечного лимита в RoundRegistry. При положительном лимите handler при очередной проверке может забыть исчерпанный раунд и позднее создать новый. Не следует переносить сюда OFFER_TTL из PENDING или формулу RESPONSE_WINDOW из ACCEPTED.
@@ Строка 735: / Строка 842: @@
 ===== Web intent: подтверждённая граница текущей маршрутизации =====
-До ''processing'' runtime сначала ищет раунд: явный round id либо активный раунд Ticket для trusted web relay. Если он найден, intent направляется туда и **не ставится** в immediate queue.
+Маршрутизация до processing:
+  - Найти явно указанный round id. Для доверенного web relay без него — найти активный раунд Ticket.
+  - Если раунд найден — отправить intent в него, пометить Ticket ready и закончить маршрутизацию.
+  - Если раунда нет — подходящий intent может попасть в immediate queue.
+Направленный в существующий раунд intent не дублируется в immediate queue.
 Для активного PRE_START раунда allowed_actions содержит start. Поэтому web ''force_majeure'' может получить ''action_mismatch'' и не дойти до ранней ветки ''process_immediate_order_intent''. При отсутствии такого раунда intent попадает в очередь и может быть обработан как переход PRE_FORCEMAJEUER. Это подтверждённое расхождение доступного web действия и его доставки при активном приглашении; фактическая конфигурация сервера не запрашивалась, исправление кода этой публикацией не выполнялось.
@@ Строка 880: / Строка 993: @@
 </sharix-bpmn>
-Narrow ''start-pre-start'' требует ''order.start_pre_start'', текущий scope, PRE_START и provider. Под lock выбирается effective time: planned берёт ''Orders.time_start'', actual — текущее backend time. Отсутствие плановой даты даёт неуспех planned-вызова. Narrow action сам не повторяет проверку «дата уже наступила»; её делает Python.
+Narrow start-pre-start проверяет:
-При успешном каноническом PROCESS пустой ''time_start_real'' заполняется effective time; уже существующее фактическое начало не перезаписывается. Пустая ''location_start_real'' заполняется через resolver, если ему доступна корректная локация. Для actual-ответа runtime передаёт допустимые location-поля победителя; planned-вызов не передаёт этот action payload. Выбор planned означает запись планового времени как эффективного начала, а не доказательство фактического действия человека ровно в эту секунду.
+  * capability order.start_pre_start и текущий scope;
+  * статус PRE_START;
+  * наличие provider;
+  * effective time под lock: planned берёт Orders.time_start, actual — текущее время backend.
+Отсутствие плановой даты даёт неуспех planned-вызова. Проверку наступления даты выполняет Python; этот narrow action её отдельно не повторяет.
+После успешного PROCESS:
+  * пустое time_start_real заполняется effective time;
+  * существующее time_start_real сохраняется;
+  * пустая location_start_real заполняется resolver, если есть корректная локация;
+  * actual-вызов передаёт допустимые location-поля победителя, planned-вызов не передаёт этот payload.
+Planned записывает плановое время как effective time. Это не свидетельство физического начала работы человеком точно в эту секунду.
 В отличие от ACCEPTED wrapper этот start-wrapper не передаёт expected_provider_id из context. Backend поддерживает такую проверку при наличии параметра, но нельзя приписывать текущему вызову привязку к старому provider id из снимка раунда.
@@ Строка 902: / Строка 1029: @@
 Счётчики send и доменных неуспехов start различны; при attempts=0 порог failures не считается достигнутым. RoundRegistry, ответы, очередь intents и счётчики — память процесса. После рестарта старое подтверждение не считается ответом на новый round id. Defer освобождает worker; внешний ответ может снять defer раньше.
-Проверяйте текущий provider/status, planned_start, auto-настройку, наличие активного раунда, маршрут intent и ответ backend. Разделяйте transport 202, приём ответа, результат стратегии и сохранённый PROCESS. Auth/HTTP/transport exceptions не равны отказу исполнителя и идут в общий retry. После commit ''ticket.changed''/''ticket.moved'' передают владение; periodic reconciliation компенсирует потерю событий.
+Порядок диагностики:
+  - Прочитать фактические статус и provider.
+  - Сверить planned_start и SERVICE_REQUEST_PRE_START_AUTO_PROCESS.
+  - Найти активный раунд и проверить, куда попал intent: в раунд или immediate queue.
+  - Различить transport 202, приём ответа, outcome стратегии и результат backend action.
+  - Подтвердить сохранённый PROCESS и последующую смену владельца очереди.
+Auth/HTTP/transport exception не является отказом исполнителя. После commit ticket.changed/ticket.moved передают владение; periodic reconciliation восстанавливает состав при потере событий.
 ===== Проверенные источники =====