Различия

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

--- sharixopen:knowledge:scenarios:service_request_forcemajeure [2026/10/28 21:26] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_forcemajeure [2026/10/31 13:21] (текущий) – [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",
-                "FORCEMAJEUER",
+                "audience_support",
-                "external resolution",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_execution",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_forcemajeuer",
+                "external_resolution",
+                "bpmn",
+                "order",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 193: / Строка 212: @@
                 "external": "ef02fe8850a746c4b9d5d7e96c20209fcffb50a66ee640a0b60c09b45d3c4e97"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/lifecycle",
+                "orders/execution",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_lifecycle",
+                "topic_orders_execution",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_forcemajeuer",
+                "external_resolution",
+                "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_forcemajeure.py",
+                    "generated_handlers/open_service_request_forcemajeure.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "acba8098346b9c76fb4da491f028fa89aafa00101d37cf3ef8f788eaee90767b",
+    "content_sha256": "45a60469f54d07f5e7a0fc1beeafff1d56c2c35fbe4b33f500eee64033ad1899",
     "schema": 1
 }
@@ Строка 202: / Строка 276: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_forcemajeure'', тип ''SERVICE_REQUEST'' (2), статус ''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#ispolnenie|Заказы → Исполнение]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_forcemajeure'', тип ''SERVICE_REQUEST'' (2), статус ''FORCEMAJEUER''. 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия, настройки и доступность подключений конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-Заказ уже находится в стадии форс-мажора. Handler сохраняет наблюдение до внешнего решения; сам результат урегулирования этим processing не выбирается.
+Вход — заказ, уже сохранённый в FORCEMAJEUER:
+  * handler наблюдает состояние до внешнего решения;
+  * причина и результат урегулирования не выбираются этим processing;
+  * из одного статуса нельзя вывести, кто принял решение и какие меры выполнены.
+В текущем processing отсутствуют:
+  * выбор следующего статуса и снятие provider;
+  * закрытие заказа;
+  * создание support Ticket;
+  * автоматическое уведомление ответственного;
+  * платёжное урегулирование.
-Это observer, а не автоматический алгоритм разрешения форс-мажора. Он не выбирает целевой статус, не снимает provider, не закрывает заказ, не создаёт support Ticket, не уведомляет автоматически ответственного и не запускает платёжное урегулирование. Наличие слова review/resolution в reason не доказывает, что человек получил задачу.
+force_majeure_resolution — локальная причина ожидания. Она не подтверждает, что человеку назначена задача.
 BPMN описательные, ''isExecutable=false''. Runtime исполняет проверенный Python из Blockly; Wiki не является исполнителем и не добавляет отсутствующие действия.
@@ Строка 380: / Строка 474: @@
 </sharix-bpmn>
-Processing проверяет локальный статус. При совпадении записывает ''force_majeure_resolution'' и назначает defer по ''SERVICE_REQUEST_FORCEMAJEURE_RECHECK_SECONDS''. Worker освобождается до следующего готового прохода. Параметр reason у defer здесь пустой: он не заменяет уже установленный waiting reason.
+Один проход в FORCEMAJEUER:
+  - Проверить локальный рабочий статус.
+  - Записать force_majeure_resolution.
+  - Назначить defer по SERVICE_REQUEST_FORCEMAJEURE_RECHECK_SECONDS.
+  - Освободить worker до следующего готового прохода.
+Пустой reason у defer использует ранее записанную причину.
 При чужом статусе handler запрашивает удаление Ticket из очереди и комнаты и возвращает None. Его processing не делает scoped order context GET и не меняет Orders/Ticket. Актуальный состав восстанавливается общим runtime через события и периодическую сверку, поэтому одна локальная проверка статуса не является отдельной проверкой всех бизнес-условий заказа.
@@ Строка 554: / Строка 655: @@
 </sharix-bpmn>
-Разрешённый внешний actor изучает актуальный заказ и использует предусмотренный action-layer с проверкой прав и области компании/объекта. В backend есть отдельное staff-действие change_status, защищённое user_can_change_order_status и каноническим переходом. Это не право observer произвольно менять стадию и не инструкция назначить любую целевую стадию без проверки её смысла и допустимости.
+Внешнее решение:
+  - Прочитать актуальные заказ и Ticket, установить причину текущей стадии.
+  - Проверить provider и определить обоснованный дальнейший путь.
+  - Уполномоченному actor выполнить предусмотренное действие через action-layer.
+  - Перечитать результат сохранения и проверить последующую передачу владельца.
+Staff-действие change_status защищено user_can_change_order_status и каноническим переходом. Наличие этой операции не даёт observer права произвольно менять стадию.
 Выбор дальнейшего пути зависит от причины проблемы, назначения исполнителя и текущего состояния заказа. Этот processing не содержит обязательного перехода в следующую стадию, срока закрытия или схемы компенсации. Сама публикация BPMN не создаёт workflow урегулирования на сервере.
@@ Строка 561: / Строка 669: @@
 ===== Не смешивать с PRE_FORCEMAJEUER =====
-Технические имена статусов сохраняют написание FORCEMAJEUER и PRE_FORCEMAJEUER. Предыдущий observer тоже только ждёт; цепочка двух observer сама по себе не переводит заказ сюда автоматически. Источник текущего FORCEMAJEUER следует устанавливать по истории разрешённых изменений, а не предполагать срабатывание таймера. Этот handler не выполняет автоматический CLOSED и не обещает платёжную компенсацию.
+Различать соседние стадии:
+  * **PRE_FORCEMAJEUER:** предыдущий observer с локальной причиной force_majeure_review.
+  * **FORCEMAJEUER:** этот observer с причиной force_majeure_resolution.
+Оба сами только ждут. Переход между ними не производится их таймерами; источник сохранённой стадии устанавливают по истории разрешённых изменений. Написание технических имён сохраняется как в коде.
 ===== Настройки и диагностика =====
@@ Строка 570: / Строка 683: @@
 | Общие ошибки 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.
+В данном processing не вызываются ни создание support Ticket, ни чтение order context. Generic ticket.transition ему не выдан; наличие capability не означает выполненной операции.
+Порядок диагностики:
+  - Прочитать фактические Ticket/Orders и историю входа в FORCEMAJEUER.
+  - Проверить provider и ответственного за внешний разбор.
+  - Сверить выбранную версию, именованный интервал и локальную причину.
+  - Проверить фактический ответ внешнего action и сохранённую стадию.
+  - Проверить wakeup или последующую periodic reconciliation.
-Проверяйте фактический Ticket/Orders, источник проблемной стадии, текущий provider, наличие отдельного ответственного и результата внешнего action. Отсутствие письма/сообщения здесь не является потерей предусмотренной рассылки: такой отправки в processing нет. Если требуется автоматическое создание обращения, уведомление или переход, сначала нужен явный согласованный контракт и отражение поведения в Blockly/генерируемом Python; добавление текста Wiki этого не реализует.
+Автоматической рассылки в этой ветви нет. Для её добавления, создания обращения или нового перехода сначала согласуют контракт и отражают поведение в Blockly/генерируемом Python. Изменение текста Wiki не реализует эти действия.
 ===== Проверенные источники =====