Различия

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

--- sharixopen:knowledge:scenarios:st_request_waiting [2026/10/28 18:19] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:st_request_waiting [2026/10/31 11:25] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 5: / Строка 5: @@
     "area": "open",
     "type": "procedure",
-    "title": "Ожидание новой заявки ST_REQUEST: обработчик и очередь",
+    "title": "Новая ST_REQUEST: ожидание, очередь и переход в ASSIGNED",
     "status": "review",
     "schema_version": 1,
@@ Строка 21: / Строка 21: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, tickets",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "ST_REQUEST",
+                "audience_developer",
-                "BPMN"
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_handlers_runtime",
+                "st_request",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 126: / Строка 137: @@
             "reviewed_on": "2026-10-28",
             "model_sha256": "ee647a94c3be9e60b66e8d9e35f2b44a0e2b3c3a0c6e4af8645c308e6caf9419"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "rewrite",
+            "batch": 4,
+            "style": "Конкретные действия, источники, условия и ограничения; определения и проверки — списками."
+        },
+        "source_review_20261031": {
+            "kind": "source_analysis_not_runtime_acceptance",
+            "sources": [
+                {
+                    "repository": "sharix-open-handlers-examples",
+                    "commit": "76e0c693b628ed4a1fa34515a3f8abdff26149bb",
+                    "path": "catalog.py",
+                    "sha256": "e3dcb72b7e620e2837adacd7af053f35b04cdff475789496d9c114e17d57dfde"
+                },
+                {
+                    "repository": "sharix-open-handlers-examples",
+                    "commit": "76e0c693b628ed4a1fa34515a3f8abdff26149bb",
+                    "path": "generated_handler_blocks/open_st_request_new.json",
+                    "sha256": "6b76b94236e6257f1f13dff9f41bb48c47352d5c512c9add0c5e53153c2dd6ff"
+                },
+                {
+                    "repository": "sharix-open-handlers-examples",
+                    "commit": "76e0c693b628ed4a1fa34515a3f8abdff26149bb",
+                    "path": "handlers/open_st_request_new.py",
+                    "sha256": "f3cc74eccbc60431fff10e4989a4e499af85c7190b2e30cba8b097639cf1a23f"
+                },
+                {
+                    "repository": "sharix-open-handlers-examples",
+                    "commit": "76e0c693b628ed4a1fa34515a3f8abdff26149bb",
+                    "path": "generated_handlers/open_st_request_new.py",
+                    "sha256": "f3cc74eccbc60431fff10e4989a4e499af85c7190b2e30cba8b097639cf1a23f"
+                },
+                {
+                    "repository": "sharix-open-handlers-backend",
+                    "commit": "50baf376e224d915a87d63240f3f339b3dda9afa",
+                    "path": "ticket_blockly_codegen.py",
+                    "sha256": "bce71eab622922f8dd0954222842349799b60e18a0ab6310cc3e5f305603661e"
+                },
+                {
+                    "repository": "sharix-open-handlers-backend",
+                    "commit": "50baf376e224d915a87d63240f3f339b3dda9afa",
+                    "path": "core/blockly_runtime.py",
+                    "sha256": "3e222150cbff315077c6c9b160d46e59856cedf6d6591d213e958c63cb2f2428"
+                },
+                {
+                    "repository": "sharix-open-handlers-backend",
+                    "commit": "50baf376e224d915a87d63240f3f339b3dda9afa",
+                    "path": "ticket_codegen_contract.json",
+                    "sha256": "0bfd2b0ebb07bd380ed3c867386536ab88ef7dfa6e13f1cd8c91d32bb02c1ae9"
+                },
+                {
+                    "repository": "sharix-open-tickets",
+                    "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                    "path": "signals.py",
+                    "sha256": "39aad8690a2e7d35cebfb052127a8130a951cbb4eea316c4f767a0a59fc5fa7e"
+                },
+                {
+                    "repository": "sharix-open-tickets",
+                    "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                    "path": "api/views/handler_workflow.py",
+                    "sha256": "f97c4b467a9a30749f5c4b86b39a833c430e57aaa1f030f70030d9b5c609d368"
+                }
+            ]
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "handlers/support",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_handlers_runtime",
+                "st_request",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "lifecycle относится к описываемому коду, а status к редакции документа; implemented не означает успешный runtime тест"
+        },
+        "classification_review": {
+            "date": "2026-10-31",
+            "source": "Содержание текущей страницы и проверенный словарь классификации",
+            "body_scope": "classification_and_navigation_only"
         }
     },
-    "content_sha256": "25b55d97b6a7db496c79b075f120a6fc142989421e030f62596e1477fc24b29f",
+    "content_sha256": "aa1202a7e01025360978d122339b2e84ea37402dce1441d448f29ad878e56e1d",
     "schema": 1
 }
 </sharix-knowledge-meta>
-====== Ожидание новой заявки ST_REQUEST: обработчик и очередь ======
+====== Новая ST_REQUEST: ожидание, очередь и переход в ASSIGNED ======
 ~~NOCACHE~~
-**Область:** ShariX Open. **Основание:** реализация обработчика ''open_st_request_new'' и планировщика очереди, проверенная 28.10.2026 по указанным ниже версиям Git. Это описание реализованного механизма ожидания, а не проект будущего процесса.
+**Назначение:** [[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#st_request|Обработчики → ST_REQUEST]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+Сценарий описывает open_st_request_new в ShariX Open. Его работа — обработать Ticket типа ST_REQUEST в статусе NEW: отложить локальную проверку либо запросить переход в ASSIGNED. Это анализ текущего кода; конфигурация и выбранная версия конкретного сервера проверяются отдельно.
+===== Какие источники определяют поведение =====
+  * **Алгоритм:** handlers_examples/generated_handler_blocks/open_st_request_new.json.
+  * **Исполняемый Python:** handlers_examples/handlers/open_st_request_new.py.
+  * **Копия результата генерации:** handlers_examples/generated_handlers/open_st_request_new.py.
+  * **Генерация:** handlers_backend/ticket_blockly_codegen.py и ticket_codegen_contract.json.
+  * **Очередь, отсрочка и сетевые операции:** handlers_backend/core/blockly_runtime.py.
+  * **Проверка обработчика на стороне API:** tickets/api/views/handler_workflow.py и capabilities каталога.
+.10.2026 Python заново получен из workspace: обе поставляемые копии совпали с результатом побайтово. Проверены хеши 11 исходников генераторов, перечисленных в контракте. Сам handler при этой проверке не запускался; серверные настройки и XMPP не проверялись.
-===== Канонический алгоритм после опубликованного исправления =====
+===== Ветви одного прохода =====
-Blockly workspace и встроенный Python текущей версии побайтово согласованы. Владелец подтвердил применение исправлений и успешные проверки. Прежнее расхождение (отсутствие автоматической ветки в workspace) устранено в опубликованном коде; историческую схему неполного workspace больше не используем как актуальный алгоритм.
+^ Условие ^ Что делает код ^ Что это означает ^
+| Ticket имеет статус NEW, STREQ_AUTOACCEPT выключен | Записывает support_assignment и откладывает проверку на ST_REQUEST_NEW_RECHECK_SECONDS. | Ожидается внешнее назначение/изменение; worker не остаётся спать на этом Ticket. |
+| Ticket имеет статус NEW, STREQ_AUTOACCEPT включён | Запрашивает ASSIGNED; после успеха отправляет Ticket open_st_request_assigned и удаляет из своей очереди с delete_room=False. | Передаётся обработка следующей стадии. Конкретного сотрудника эта ветвь не выбирает и assigned_to не заполняет. |
+| На проверку пришёл Ticket уже с другим статусом | Убирает локальное состояние и запрашивает удаление комнаты уведомлений. | Данный handler прекращает обработку. Сам Ticket из backend не удаляется. |
+| Scoped API перехода вернул 404 | change_status убирает локальный снимок и возвращает False. | Ticket больше не доступен в рабочей области этого handler; повторный переход в этом проходе не выполняется. |
+| Переход или отправка завершились другой ошибкой | Ошибка передаётся общему runtime для его обработки отказа и повторов. | Передачу нельзя объявлять успешно завершённой по одному намерению отправки. |
-При отключённом ''STREQ_AUTOACCEPT'' обработчик ждёт ручного назначения. При включённом запрашивает ''ASSIGNED'', передаёт Ticket в ''open_st_request_assigned'' и освобождает текущую очередь с сохранением комнаты при успешной передаче. 404 scoped API прекращает эту обработку; иная ошибка API/отправки передаётся общему retry/defer. Выбранная локальная версия на конкретном сервере по-прежнему требует собственной проверки.
+STREQ_AUTOACCEPT — переключатель автоматической ветви. Его имя не означает успешной проверки документа, выдачи роли или выбора сотрудника. В данном алгоритме явно выполняется переход состояния и передача Ticket; дальнейшее решение относится к следующему сценарию.
 ===== Полный алгоритм и очередь (BPMN) =====
+Схема описательная: isExecutable=false. Дорожки показывают worker и планировщик, а deferred_until обозначает вычисленный локальный срок, не отдельную настройку установки. Просмотр схемы не запускает процесс и не создаёт таймер.
 <sharix-bpmn>
 <?xml version="1.0" encoding="UTF-8"?>
@@ Строка 481: / Строка 620: @@
 </sharix-bpmn>
-===== Назначение и границы ручного ожидания =====
+===== Как устроено ручное ожидание =====
-Процесс начинается, когда Ticket передан обработчику ''open_st_request_new''. Схема показывает автоматическую ветку и ручное ожидание; две дорожки обозначают worker и планировщик. Действия пользователя и backend-события рассматриваются отдельно от локального defer. Из одного значения ''support_assignment'' полный сценарий согласования не выводится.
+  - Handler сверяет текущий статус Ticket с NEW.
+  - При выключенном STREQ_AUTOACCEPT сохраняет в памяти причину support_assignment.
+  - defer_ticket_for_setting читает ST_REQUEST_NEW_RECHECK_SECONDS через конфигурацию handlers; требуется положительное целое значение, минимум одна секунда. Значение конкретного сервера по этой статье не определяется.
+  - Ticket получает локальный срок defer, текущий проход заканчивается, а очередь может выполнять другие готовые элементы.
+  - После срока планировщик возвращает элемент в готовую очередь. Фактическое начало зависит от доступного worker и готовности XMPP; это не обещание запуска ровно в момент срока.
+  - Распознанное внешнее событие может снять отсрочку раньше. request_ticket_ready очищает локальный defer и будит планировщик; обновлённое состояние заново участвует в решении.
-BPMN используется для описания. Просмотр схемы в Wiki не запускает обработчик и не создаёт таймер. В XML установлен ''isExecutable=false''; ''deferred_until'' — условное обозначение вычисленного срока, а не имя настройки установки.
+Причина ожидания и срок находятся в памяти процесса. После restart они не восстанавливаются как долговечное бизнес-обязательство: очередь получает актуальные Ticket из backend и оценивает их заново. Такой defer не заменяет журнал решений сотрудника или сохранённый SLA-таймер.
+===== Передача NEW → ASSIGNED =====
+  - Обработчик вызывает scoped transition API с capability ticket.transition.
+  - Backend ограничивает Ticket типом и рабочим статусом handler, проверяет допустимость перехода и сохраняет Event в транзакции.
+  - После commit ticket.changed адресуется новому handler, а ticket.moved — прежнему.
+  - Сама Python-ветвь NEW после успешного перехода также отправляет Ticket в open_st_request_assigned и убирает его из своей очереди, сохраняя комнату при этой передаче.
-===== Как проходит ожидание =====
+Смена Ticket.status, попытка XMPP-отправки и фактическая работа следующего handler — отдельные наблюдаемые результаты. Если отправка после смены статуса не удалась, уже сохранённый переход не становится автоматически отменённым. Подробности внешних участников и восстановления — [[sharixopen:knowledge:scenarios:st_request_assigned|сценарий ASSIGNED]].
-  - Обработчик получает Ticket и проверяет соответствие статусу ''NEW'', указанному в его workspace.
-  - Если статус соответствует и ''STREQ_AUTOACCEPT'' отключён, обработчик записывает локальную причину ожидания ''support_assignment'' и назначает повторную проверку через ''ST_REQUEST_NEW_RECHECK_SECONDS''. Число секунд берётся из действующей конфигурации handlers; по одной схеме его определить нельзя. Реализация требует положительное целое значение, минимум одна секунда.
-  - Текущий проход обработчика завершается. Отложенный Ticket не занимает рабочий поток ожиданием; очередь может обрабатывать другие готовые элементы.
-  - При наступлении срока планировщик снимает отсрочку и возвращает Ticket в готовую очередь. Следующий проход снова проверяет статус. Истечение таймера означает готовность к запуску, а не гарантию запуска в ту же секунду: учитываются доступные workers и готовность XMPP.
-  - Распознанное внешнее событие может сделать Ticket готовым раньше срока. Например, ''request_ticket_ready'' снимает локальную отсрочку и будит планировщик. События обновления Ticket обрабатываются с получением актуального состояния из backend. После пробуждения заново проверяется статус, решение прежнего прохода не считается вечным.
-  - Если Ticket дошёл до проверки обработчика уже с другим статусом, ветка ELSE убирает его из локальной очереди и запрашивает удаление комнаты уведомлений. Это прекращение обработки данным обработчиком; оно не означает удаления самого Ticket из backend или завершения всей заявки.
-===== При передаче из NEW в ASSIGNED =====
+===== Сверка очереди и ошибки =====
-При каноническом переходе backend после commit направляет ''ticket.changed'' новому ''open_st_request_assigned'', а ''ticket.moved'' — прежнему ''open_st_request_new''. Второе событие запрашивает исключение старого локального снимка, а не повторное бизнес-решение в NEW. При потере сообщения состав очереди восстанавливает periodic reconciliation. Подробные внешние участники, объектные права, два события и fallback разобраны в [[sharixopen:knowledge:scenarios:st_request_assigned|следующем сценарии ASSIGNED]].
+Runtime периодически сопоставляет локальный состав с backend. В результате он может:
-===== Дополнительные пути runtime =====
+  * обновить снимок Ticket;
-Схема показывает основной цикл одного Ticket. Периодическая сверка очереди с backend также может обновить снимок, снять отсрочку либо исключить Ticket, который больше не входит в область данного обработчика. Поэтому не каждое изменение статуса обязательно дойдёт до ветки ELSE на картинке: runtime может убрать элемент раньше при сверке или событии удаления.
+  * сделать обновлённый элемент готовым;
+  * исключить Ticket, который больше не входит в рабочую область;
+  * восстановить состав после пропущенного события или перезапуска.
-Отсрочка и причина ожидания хранятся в памяти процесса. После перезапуска прежний срок таймера не восстанавливается как сохранённое бизнес-обязательство: очередь загружает актуальные Ticket из backend и оценивает их заново. Не следует использовать этот локальный механизм как доказательство долговечного SLA-таймера или как журнал решений сотрудника.
+Поэтому изменение статуса не обязано доходить до ELSE на схеме: элемент может быть исключён раньше по событию или успешной сверке. Ошибка запроса сверки не доказывает исчезновения Ticket: runtime сохраняет локальный снимок и пишет диагностику. Ошибки загрузки, исчерпание попыток и остановка относятся к общему runtime; эта диаграмма не разворачивает все его аварийные ветви.
-Ошибки загрузки из backend, повторные события, остановка процесса и исчерпание попыток относятся к общему runtime и не развёрнуты в отдельные ветки этой компактной схемы. Отказ API при сверке не доказывает исчезновения Ticket: runtime сохраняет локальный снимок и пишет диагностику. Эти пути нужно учитывать при поиске неисправности.
+===== Что записать при разборе зависания =====
+  * ID Ticket, его тип и сохранённый статус в backend.
+  * Фактически выбранную версию handler, workspace и Python.
+  * Действующие значения STREQ_AUTOACCEPT и ST_REQUEST_NEW_RECHECK_SECONDS — без секретов конфигурации.
+  * Был ли Ticket принят в очередь и есть ли локальные причина ожидания/срок defer.
+  * Какое событие или успешная сверка поступили после этого.
+  * Готовность XMPP и наличие свободного worker.
+  * Последний restart процесса: после него старые локальные признаки не считаются сохранёнными.
+  * Результат transition API и отдельно результат отправки следующему handler, если выполнялась автоматическая ветвь.
-===== Что проверять при диагностике =====
+Если статус уже ASSIGNED, разбирать его обработку нужно у следующего handler, а не повторно менять NEW по старому снимку. При 404 проверяют область и актуальный статус; права API-ключа не расширяют ради прохождения запроса.
-  * Соответствует ли Ticket типу и рабочему статусу обработчика; не был ли он исключён из очереди после актуальной сверки backend.
-  * Какое значение ''ST_REQUEST_NEW_RECHECK_SECONDS'' действительно настроено у запущенного экземпляра handlers.
-  * Есть ли причина ожидания и локальный срок defer; получал ли планировщик событие, снимающее отсрочку раньше срока.
-  * Есть ли свободный worker и готово ли XMPP-соединение. Готовность Ticket и фактический запуск — разные моменты.
-  * Не перезапускался ли процесс: локальные признаки предыдущего ожидания после этого нельзя считать сохранёнными.
-  * Соответствуют ли установленные workspace и runtime версиям ниже. Схема подтверждает изученный код, но сама по себе не подтверждает состав конкретной работающей установки.
-===== Проверенные источники =====
+===== Связанные материалы =====
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/generated_handler_blocks/open_st_request_new.json|sharix-open-handlers-examples / generated_handler_blocks/open_st_request_new.json]] — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
+  * [[sharixopen:knowledge:modules:handlers|Устройство обработчиков и проверка Blockly]].
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/handlers/open_st_request_new.py|sharix-open-handlers-examples / handlers/open_st_request_new.py]] — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
+  * [[sharixopen:knowledge:domain:st_request|Назначение ST_REQUEST]].
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/catalog.py|sharix-open-handlers-examples / catalog.py]] — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
+  * [[sharixopen:knowledge:operations:runtime_health|Диагностика runtime]].
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/core/blockly_runtime.py|sharix-open-handlers-backend / core/blockly_runtime.py]] — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
+  * [[sharixopen:knowledge:scenarios:start|Указатель сценариев]].
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/core/requesters.py|sharix-open-handlers-backend / core/requesters.py]] — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/signals.py|sharix-open-tickets / signals.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/services/handler_wakeup.py|sharix-open-tickets / services/handler_wakeup.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/utils.py|sharix-open-tickets / utils.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/views/ticket_detail.py|sharix-open-tickets / views/ticket_detail.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/api/views/handler_workflow.py|sharix-open-tickets / api/views/handler_workflow.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/api/views/ticket.py|sharix-open-tickets / api/views/ticket.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/api/permissions.py|sharix-open-tickets / api/permissions.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/urls.py|sharix-open-tickets / urls.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/lib/tickets.py|sharix-open-tickets / lib/tickets.py]] — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
-Каноническая пара NEW заново проверена реальным renderer. Изучены также события смены владельца, API/ACL и queue/defer; на схеме нет значений реальных секретов или предположений о сроках конкретного сервера.
+===== Исходники, сверенные 31.10.2026 =====
+Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, конфигурации или выполнения сценария на сервере.
-===== Связанные материалы =====
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/catalog.py|sharix-open-handlers-examples: catalog.py]].
-  * [[sharixopen:knowledge:scenarios:st_request_assigned|Следующая стадия ASSIGNED: ручное начало работы и автоматический переход]]
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/generated_handler_blocks/open_st_request_new.json|sharix-open-handlers-examples: generated_handler_blocks/open_st_request_new.json]].
-  * [[sharixopen:knowledge:modules:handlers|Обработчики, Blockly и граница выполнения]]
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/handlers/open_st_request_new.py|sharix-open-handlers-examples: handlers/open_st_request_new.py]].
-  * [[sharixopen:knowledge:domain:st_request|ST_REQUEST: запросы документов и проверок]]
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-examples/src/commit/76e0c693b628ed4a1fa34515a3f8abdff26149bb/generated_handlers/open_st_request_new.py|sharix-open-handlers-examples: generated_handlers/open_st_request_new.py]].
-  * [[sharixopen:knowledge:operations:runtime_health|Диагностика runtime и обработчиков]]
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/ticket_blockly_codegen.py|sharix-open-handlers-backend: ticket_blockly_codegen.py]].
-  * [[sharixopen:knowledge:scenarios:start|Сценарии использования и проверки]]
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/core/blockly_runtime.py|sharix-open-handlers-backend: core/blockly_runtime.py]].
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/ticket_codegen_contract.json|sharix-open-handlers-backend: ticket_codegen_contract.json]].
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/signals.py|sharix-open-tickets: signals.py]].
+  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-tickets/src/commit/fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14/api/views/handler_workflow.py|sharix-open-tickets: api/views/handler_workflow.py]].
 ~~SHARIX_KNOWLEDGE_RELATED~~