Различия

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

--- sharixopen:knowledge:scenarios:service_request_template [2026/10/28 21:46] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:service_request_template [2026/10/31 11:25] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 19: / Строка 19: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "SERVICE_REQUEST",
+                "audience_developer",
-                "TEMPLATE",
+                "audience_support",
-                "order intents",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_creation",
+                "topic_orders_lifecycle",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_template",
+                "order_intent",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "order"
             ]
         },
@@ Строка 178: / Строка 191: @@
             "utility": "tools/expand_bpmn_view_bounds.py",
             "utility_sha256": "f878658b0115773e34f6c3eec72eba5984d873e60d8e2a4336b3dfb2a8026d87"
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "orders/creation",
+                "orders/lifecycle",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_orders_creation",
+                "topic_orders_lifecycle",
+                "topic_handlers_runtime",
+                "service_request",
+                "ticket_template",
+                "order_intent",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "order"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "lifecycle относится к описываемому коду, а status к редакции документа; implemented не означает успешный runtime тест"
+        },
+        "classification_review": {
+            "date": "2026-10-31",
+            "source": "Содержание текущей страницы и проверенный словарь классификации",
+            "body_scope": "rewrite"
+        },
+        "source_review_20261031": {
+            "kind": "source_analysis_not_runtime_acceptance",
+            "evidence_field": "extensions.source_evidence",
+            "checked_on": "2026-10-31",
+            "all_original_evidence_hashes_match_fresh_git": true,
+            "canonical_generation": "Both runnable and generated copies match; no handler executed."
         }
     },
-    "content_sha256": "fdef1ba86eb443f0e1c9099033265edd78d49d9c0c08e738bdcdcc64c837eba7",
+    "content_sha256": "9a3f290907a8bc2d7f8acc45be47dd0f9694ad3218e2de6f986792e0f181df8d",
     "schema": 1
 }
@@ Строка 187: / Строка 251: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_service_request_template'', тип ''SERVICE_REQUEST'' (2), рабочий статус ''TEMPLATE'' (210). Опубликованный Python на 28.10.2026 побайтово совпадает с канонической генерацией его 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#sozdanie_i_chernovik|Заказы → Создание и черновик]] · [[sharixopen:knowledge:classification:topics#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_service_request_template'', тип ''SERVICE_REQUEST'' (2), рабочий статус ''TEMPLATE'' (210). 31.10.2026 опубликованные исходники повторно получены из Git. Обе Python-копии заново сопоставлены с результатом генерации Blockly; проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранную версию, конфигурацию и внешние подключения сервера проверяют отдельно.
 ===== Назначение и границы =====
-Handler сопровождает уже существующий черновик заказа: принимает подходящее пользовательское намерение, проверяет срок автоматического закрытия, напоминает автору о размещении и освобождает worker до следующего прохода. Он не создаёт заказ и не выбирает исполнителя в фоне только из-за наличия черновика.
+Handler сопровождает существующий черновик:
+  * принимает допустимое пользовательское намерение;
+  * проверяет срок автоматического закрытия;
+  * при необходимости напоминает автору о размещении;
+  * освобождает worker до следующего прохода.
+Новый заказ здесь не создаётся. Наличие черновика само по себе не запускает фоновый выбор исполнителя.
+Приоритет действий в TEMPLATE:
+  - Сначала обработать разрешённый book/cancel.
+  - При успешном действии или stale scope завершить проход.
+  - Если intent отсутствует или каноническое действие отклонено — продолжить проверку черновика.
+  - Только затем проверить срок автоматического закрытия.
-Пользовательское ''book''/''cancel'' обрабатывается **до** проверки срока закрытия. Успешное действие либо устаревший scope завершают этот проход. Если intent не найден или каноническое пользовательское действие отклонено, текущий проход продолжает обычную проверку черновика. Очерёдность важна: дата закрытия не является предварительным фильтром перед всеми пользовательскими намерениями этой стадии.
+Дата закрытия не является предварительным фильтром перед всеми пользовательскими намерениями.
 SERVICE_REQUEST не должен менять бизнес-состояние через универсальный ''ticket.transition'': каталог TEMPLATE объявляет узкие ''order.context'', ''order.apply_user_intent'', ''order.close_template'' и необходимые read/notification возможности. Backend order actions проверяют актуальный заказ и его lifecycle.
@@ Строка 949: / Строка 1035: @@
 В relay для TEMPLATE доступны book/cancel по фактическим правам пользователя; subscription-access заказы не получают этот набор интерактивных действий. Текущий ''user_is_order_client'' проверяет автора заказа либо пользователя личного Client. Одно название LDAP-группы или статус «клиент платформы» не заменяют связь пользователя с этим заказом ShariX Open.
-Relay определяет handler по текущему Ticket.status, сохраняет actor user id/JID, event id, order/ticket id и стадию, отправляет ''order.action.intent''. Сам relay заказ не меняет. Runtime принимает такой intent только от настроенного доверенного relay JID и ''transport=web_relay'', проверяет структуру и стадию, отсекает известный дубликат event id и ставит намерение в процессную очередь. Произвольное XMPP-сообщение не является разрешением разместить заказ.
+Relay определяет handler по Ticket.status и передаёт:
+  * actor user ID и JID;
+  * event ID;
+  * order ID и ticket ID;
+  * стадию;
+  * сообщение order.action.intent.
+Relay сам заказ не меняет. Runtime принимает intent от настроенного доверенного relay JID с transport=web_relay, проверяет структуру/стадию, отсекает известный event ID и ставит намерение в память процесса. Произвольное XMPP-сообщение не разрешает размещение заказа.
 При применении intent backend заново проверяет активного actor, соответствие переданного JID, текущий связанный заказ и права канонического действия. Очередь и дедупликация runtime находятся в памяти: это не durable гарантия исполнения при рестарте и не exactly-once подтверждение. После 202 нужно смотреть фактический результат/статус заказа, а не считать размещение уже выполненным.
@@ Строка 1188: / Строка 1282: @@
 </sharix-bpmn>
-Первое напоминание не отправляется раньше ''Ticket.created_at + SERVICE_REQUEST_TEMPLATE_REMINDER_INTERVAL_SECONDS''. Далее учитывается последняя успешная отправка в памяти процесса и тот же интервал. Нет/не разбирается created_at — helper логирует проблему и пропускает напоминание, не закрывая черновик по этой причине.
+Условия напоминания:
+  * первая отправка не раньше Ticket.created_at + SERVICE_REQUEST_TEMPLATE_REMINDER_INTERVAL_SECONDS;
+  * последующие отправки учитывают последнюю успешную отправку в памяти процесса и тот же интервал;
+  * при отсутствующем или неверном created_at helper пишет диагностику и пропускает напоминание.
+Невозможность определить возраст для напоминания сама по себе не закрывает черновик.
 Если есть planned_start и наступило ''close_at − SERVICE_REQUEST_TEMPLATE_CLOSE_WARNING_SECONDS'', в сообщение добавляется дата автоматического закрытия. Она форматируется в локальной временной зоне runtime; не следует автоматически считать её часовой зоной пользователя. Напоминание не является гарантированным предварительным уведомлением: интервалы, фактические проходы, реквизиты и доступность XMPP влияют на отправку.
@@ Строка 1210: / Строка 1310: @@
 ===== Диагностика =====
-Различайте 202 relay, извлечённый intent, доменный результат book/cancel, фактическую стадию Orders/Ticket и доставку wakeup. Для автоматического закрытия проверяйте planned_start, именованный offset и выбранный runtime; для напоминания — created_at, последний send в памяти, warning window, защищённый получатель и транспорт. Одна страница черновика не доказывает, что пользовательский запрос был исполнен.
+При диагностике различать:
+  * 202 от relay и фактическое выполнение пользовательского действия;
+  * извлечённый intent и доменный результат book/cancel;
+  * фактическую стадию Orders/Ticket и доставку wakeup;
+  * для автоматического закрытия — planned_start, именованный offset и выбранный runtime;
+  * для напоминания — created_at, последний send в памяти, warning window, получателя и транспорт.
+Одна открытая страница черновика не доказывает исполнения пользовательского запроса.
 ===== Проверенные источники =====