Различия

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

--- sharixopen:knowledge:scenarios:service_request_preforcemajeure [2026/10/28 21:23] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_preforcemajeure [2026/10/31 11:50] (текущий) – [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, tickets, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "PRE_FORCEMAJEUER",
+                "audience_support",
-                "external resolution",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_assignment",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_pre_forcemajeuer",
+                "external_resolution",
+                "bpmn",
+                "ticket",
+                "order",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 180: / Строка 199: @@
                 "path": "settings_schema.py",
                 "sha256": "8ea8494405c6808834f4be7b171ffb8a969e1dd9b1654d36a8c21fbc9e3599c3"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 193: / Строка 218: @@
                 "external": "bc643b441668fff95b352216b35b698922466e6fe4d1cf1682f83d26f7cbf29a"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/lifecycle",
+                "orders/assignment",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_assignment",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_pre_forcemajeuer",
+                "external_resolution",
+                "bpmn",
+                "ticket",
+                "order",
+                "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": "Все исходные commits и SHA-256 повторно совпали после git fetch; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "both_python_copies_match": true,
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "57fc0a705aa1e32efe0440927f9c74796394bc429a338eec28c3bbdb2e95d1f6",
+    "content_sha256": "23b763329b879ecb3509856d48f9de331f7a2a63b706143406b94d7f67797d65",
     "schema": 1
 }
@@ Строка 202: / Строка 278: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_preforcemajeure'', тип ''SERVICE_REQUEST'' (2), статус ''PRE_FORCEMAJEUER''. Проверено 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#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#naznachenie|Заказы → Назначение]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_preforcemajeure'', тип ''SERVICE_REQUEST'' (2), статус ''PRE_FORCEMAJEUER''. 31.10.2026 исходники повторно получены из Git: обе Python-копии совпали с новой канонической генерацией Blockly, проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранная серверная версия, её настройки и работающие API/XMPP проверяются отдельно.
 ===== Назначение и границы =====
-Ожидается внешний разбор проблемного заказа: назначение могло отсутствовать после PENDING либо сохраняться после активной стадии.
+В PRE_FORCEMAJEUER могут оказаться разные ситуации:
+  * **Поиск в PENDING завершился без назначения:** provider отсутствует.
+  * **Проблема в активном PRE_START/PROCESS:** provider сохраняется.
+Наличие исполнителя не доказывает возможность продолжения; причина, текущий этап и фактическое назначение требуют внешнего разбора.
+Текущий observer выполняет только наблюдение. В его processing отсутствуют:
+  * выбор следующего бизнес-статуса и снятие provider;
+  * закрытие заказа;
+  * создание отдельного support Ticket;
+  * автоматическое уведомление ответственного;
+  * платёжное урегулирование.
-Это observer, а не автоматический алгоритм разрешения форс-мажора. Он не выбирает целевой статус, не снимает provider, не закрывает заказ, не создаёт support Ticket, не уведомляет автоматически ответственного и не запускает платёжное урегулирование. Наличие слова review/resolution в reason не доказывает, что человек получил задачу.
+Локальная причина force_majeure_review не означает, что человеку назначена задача или доставлено уведомление.
 BPMN описательные, ''isExecutable=false''. Runtime исполняет проверенный Python из Blockly; Wiki не является исполнителем и не добавляет отсутствующие действия.
@@ Строка 380: / Строка 477: @@
 </sharix-bpmn>
-Processing проверяет локальный статус. При совпадении записывает ''force_majeure_review'' и назначает defer по ''SERVICE_REQUEST_PRE_FORCEMAJEURE_RECHECK_SECONDS''. Worker освобождается до следующего готового прохода. Параметр reason у defer здесь пустой: он не заменяет уже установленный waiting reason.
+Один проход при своём локальном статусе:
+  - Записать force_majeure_review как причину ожидания.
+  - Рассчитать defer по SERVICE_REQUEST_PRE_FORCEMAJEURE_RECHECK_SECONDS.
+  - Освободить worker до следующей готовности.
+Пустой reason у defer сохраняет уже установленную причину. Таймер назначает повтор наблюдения, а не срок автоматического решения.
 При чужом статусе handler запрашивает удаление Ticket из очереди и комнаты и возвращает None. Его processing не делает scoped order context GET и не меняет Orders/Ticket. Актуальный состав восстанавливается общим runtime через события и периодическую сверку, поэтому одна локальная проверка статуса не является отдельной проверкой всех бизнес-условий заказа.
@@ Строка 554: / Строка 657: @@
 </sharix-bpmn>
-Разрешённый внешний actor изучает актуальный заказ и использует предусмотренный action-layer с проверкой прав и области компании/объекта. В backend есть отдельное staff-действие change_status, защищённое user_can_change_order_status и каноническим переходом. Это не право observer произвольно менять стадию и не инструкция назначить любую целевую стадию без проверки её смысла и допустимости.
+Внешний разбор проводится вне observer:
+  - Прочитать актуальный заказ и Ticket, установить причину проблемного этапа и проверить provider.
+  - Определить ответственного и обоснованный дальнейший путь: текущий processing этого не делает.
+  - Использовать предусмотренный action-layer с проверкой прав и области компании/объекта.
+  - Прочитать результат сохранения; затем проверить передачу новому handler.
+Staff-действие change_status защищено user_can_change_order_status и каноническим переходом. Наличие этой операции не разрешает произвольному actor менять любую стадию.
 Выбор дальнейшего пути зависит от причины проблемы, назначения исполнителя и текущего состояния заказа. Этот processing не содержит обязательного перехода в следующую стадию, срока закрытия или схемы компенсации. Сама публикация BPMN не создаёт workflow урегулирования на сервере.
@@ Строка 561: / Строка 671: @@
 ===== Источники входа в PRE_FORCEMAJEUER =====
-PENDING может перейти сюда по общему пределу поиска без provider. Активные PRE_START/PROCESS — через предусмотренный problem action с сохранённым provider. Обработчик наблюдения не уравнивает эти ситуации и не считает проблему автоматически разрешённой. Даже наличие provider не доказывает возможность продолжения без разбора. Автоматического PRE_FORCEMAJEUER→FORCEMAJEUER в этом processing нет.
+Проверенные источники входа:
+  * **PENDING:** общий предел поиска; каноническое действие требует отсутствия provider.
+  * **PRE_START/PROCESS:** предусмотренный problem action; каноническое действие требует существующего и актуального provider.
+Observer не объединяет причины и не разрешает их автоматически. Переход PRE_FORCEMAJEUER → FORCEMAJEUER в этом processing отсутствует.
 ===== Настройки и диагностика =====
@@ Строка 570: / Строка 685: @@
 | Общие ошибки runtime | ''DEFERRED_TICKET_RECHECK_SECONDS'', ''processing_error'' |
-Каталог выдаёт SERVICE_OBSERVE_CAPABILITIES: ticket.read, ticket.support.create и order.context. Но эти capability не равны исполнению: текущий processing не вызывает создание support Ticket или чтение order context, generic ticket.transition отсутствует. Нельзя утверждать, что заявка поддержки уже создана лишь из-за наличия такого capability.
+Каталог выдаёт SERVICE_OBSERVE_CAPABILITIES:
+  * ticket.read;
+  * ticket.support.create;
+  * order.context.
+Это границы разрешённых API, а не перечень выполненных операций. Текущий processing не читает order context и не создаёт support Ticket; generic ticket.transition ему не выдан.
+Для диагностики записать:
+  - Фактические Ticket/Orders и источник входа в проблемную стадию.
+  - Текущий provider и подтверждённого ответственного за внешний разбор.
+  - Причину ожидания, настройку повтора и выбранный handler.
+  - Результат внешнего action и сохранённый статус.
+  - Получение wakeup либо последующую periodic reconciliation.
-Проверяйте фактический Ticket/Orders, источник проблемной стадии, текущий provider, наличие отдельного ответственного и результата внешнего action. Отсутствие письма/сообщения здесь не является потерей предусмотренной рассылки: такой отправки в processing нет. Если требуется автоматическое создание обращения, уведомление или переход, сначала нужен явный согласованный контракт и отражение поведения в Blockly/генерируемом Python; добавление текста Wiki этого не реализует.
+Автоматической рассылки в processing нет, поэтому её отсутствие само по себе не означает сбой доставки. Для добавления уведомления, создания обращения или перехода сначала согласуют контракт, затем отражают поведение в Blockly и сгенерированном Python. Текст Wiki отсутствующую реализацию не создаёт.
 ===== Проверенные источники =====