Различия

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

--- sharixopen:knowledge:scenarios:st_request_reopened [2026/10/28 21:46] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:st_request_reopened [2026/10/31 11:50] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 16: / Строка 16: @@
             "ShariXKnowledgeOpenKnowledgeOperationsRuntimehealth",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 22: / Строка 28: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, tickets",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "ST_REQUEST",
+                "audience_developer",
-                "REOPENED",
+                "audience_support",
-                "BPMN"
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_handlers_runtime",
+                "st_request",
+                "ticket_reopened",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "verification_workflow"
             ]
         },
@@ Строка 114: / Строка 132: @@
                 "path": "services/handler_wakeup.py",
                 "sha256": "c9fdc62a18301fd7c075395c697d5b1c738c77713aa71fcbb5ab097e173d98de"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 138: / Строка 162: @@
             "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": [
+                "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",
+                "ticket_reopened",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "verification_workflow"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "Конкретизация шагов, участников, условий, результатов и диагностики; перечисления; BPMN сохранены побайтово",
+            "current_source_records_verified": 14,
+            "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": "55d7738471612d80fd5974ec86c40a3d89a1afb795033c388e77c2e2052a4028",
+    "content_sha256": "04b9c674b51b830ef0fa6361d62385b1930428591c919b2e4082fc983eb9b5e4",
     "schema": 1
 }
@@ Строка 147: / Строка 219: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_st_request_reopened'', тип ''ST_REQUEST'' (1), рабочий статус ''REOPENED'' (110). Опубликованная встроенная реализация изучена на 28.10.2026; Python побайтово совпадает с канонической генерацией из Blockly. Выбранная версия на сервере проверяется отдельно.
+**Назначение:** [[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]].
+**Область:** ShariX Open. **Обработчик:** ''open_st_request_reopened'', тип ''ST_REQUEST'' (1), рабочий статус ''REOPENED'' (110). 31.10.2026 исходники повторно получены из Git: обе Python-копии совпали с новой канонической генерацией Blockly, проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранная серверная версия, её настройки и работающие API/XMPP проверяются отдельно.
 ===== Назначение и границы =====
-Обработчик сопровождает уже переоткрытое обращение и ждёт повторного назначения. Он не выбирает человека, не меняет ''assigned_to'', не возвращает Ticket в ''ASSIGNED'' самостоятельно и не возобновляет автоматически исполнение содержания заявки. ''STREQ_AUTOACCEPT'' здесь не используется.
+Вход — уже переоткрытое обращение. Обработчик:
+  * ждёт повторного назначения;
+  * не выбирает человека и не заполняет assigned_to;
+  * не переводит Ticket в ASSIGNED самостоятельно;
+  * не возобновляет автоматически исполнение содержания заявки.
+STREQ_AUTOACCEPT в этой ветви не используется.
+Для профильной проверки само переоткрытие не создаёт:
+  * новую попытку RequirementCheck;
+  * новую редакцию документа;
+  * очистку прежнего verification_runtime.completed.
-Переход в ''REOPENED'' и новое доменное решение — разные факты. Для профильной проверки переоткрытие само по себе не создаёт новую попытку RequirementCheck, не меняет редакцию документа и не очищает прежний marker ''verification_runtime.completed''. Повторное подтверждение следует оформлять с учётом доменной попытки/редакции; нельзя ожидать нового результата лишь от повторного прохождения старого Ticket. Граница marker описана в сценариях [[sharixopen:knowledge:scenarios:st_request_done|DONE]] и [[sharixopen:knowledge:scenarios:st_request_wontfix|WONTFIX]].
+Повторное подтверждение оформляют с учётом доменной попытки и редакции. Прохождение старого Ticket ещё раз не гарантирует нового результата. Граница marker описана в [[sharixopen:knowledge:scenarios:st_request_done|DONE]] и [[sharixopen:knowledge:scenarios:st_request_wontfix|WONTFIX]].
 ===== Проход и локальное ожидание (BPMN) =====
@@ Строка 376: / Строка 469: @@
 </sharix-bpmn>
-В своём рабочем статусе handler записывает локальную причину ''support_reassignment'' и назначает повтор по ''ST_REQUEST_REOPENED_RECHECK_SECONDS''. Пустой reason в Blockly-примитиве defer использует уже сохранённую причину. Это состояние runtime и запись журнала, а не комментарий в Ticket и не уведомление пользователю.
+Один проход в своём рабочем статусе:
+  - Записать локальную причину support_reassignment.
+  - Назначить defer по ST_REQUEST_REOPENED_RECHECK_SECONDS. Пустой reason использует ранее сохранённую причину.
+  - Завершить проход и освободить worker.
+Причина относится к runtime и журналу. Она не добавляет комментарий в Ticket и не уведомляет пользователя.
 Worker после прохода освобождается. Когда срок ''deferred_until'' наступает либо получена новая authoritative revision, Ticket становится готов к повторной проверке; одинаковый снимок не сбрасывает ожидание. Фактический запуск зависит от свободного worker и соединения XMPP. Defer хранится в памяти; после рестарта состав очереди сверяется с backend заново.
@@ Строка 592: / Строка 691: @@
 </sharix-bpmn>
-Пользователь должен иметь доступ к конкретному Ticket и право смены статуса. Авторство само по себе такого права не даёт. Канонические view/API проверяют объектный доступ и разрешённый переход lifecycle до сохранения; связанные с заказом Ticket не должны обходить жизненный цикл заказа через общую форму.
+Для внешнего решения проверяются отдельно:
-Из ''REOPENED'' текущий lifecycle разрешает ''ASSIGNED'', ''WONTFIX'' либо ''DUPLICATE''. Выбор ''ASSIGNED'' меняет стадию, но не является автоматическим заполнением ''assigned_to'': назначенного человека и решение о дальнейшей работе нужно проверить отдельно. Handler REOPENED не выполняет этот выбор за пользователя.
+  * право чтения конкретного Ticket;
+  * право менять его статус;
+  * разрешённый переход текущего lifecycle;
+  * доменная граница: связанный заказ должен изменяться через действия заказа.
-После commit backend публикует события изменения владельца. ''ticket.moved'' направляется прежнему handler и исключает локальный снимок; если worker уже выполняется, применяется pending discard до его завершения. Для новой стадии с зарегистрированным handler предназначен ''ticket.changed''. Для ''CLOSED'' отдельного ''open_st_request_closed'' в каталоге нет.
+Авторство обращения само по себе не даёт права смены статуса.
+Из REOPENED допустимы:
+  * **ASSIGNED:** вернуть обращение на стадию назначения; выбранного человека проверить отдельно.
+  * **WONTFIX:** зафиксировать отказ от выполнения, далее действует соответствующий сценарий.
+  * **DUPLICATE:** признать обращение дубликатом, далее действует сценарий ожидания закрытия.
+Переход в ASSIGNED сам по себе не заполняет assigned_to. Handler REOPENED не выбирает исход за пользователя.
+После commit backend направляет:
+  * **ticket.moved прежнему handler:** локальный снимок исключается; для выполняющегося worker удаление откладывается до завершения прохода.
+  * **ticket.changed новому зарегистрированному handler:** новое состояние ставится в его очередь.
+У CLOSED нет отдельного open_st_request_closed в каталоге. Сохранение статуса и доставка события — разные операции.
 XMPP-доставка best effort и не является частью транзакции сохранения Ticket. Потерю сообщения восстанавливает scoped periodic reconciliation по ''INTERVAL_TIME_BD_REQ''. Успешный список без Ticket позволяет убрать прежний снимок; ошибка списка не должна трактоваться как пустая очередь. Новый локальный проход не заменяет проверку актуального backend-состояния.
@@ Строка 603: / Строка 720: @@
 Именованный интервал — ''ST_REQUEST_REOPENED_RECHECK_SECONDS'', минимум одна секунда; реальное значение конкретного сервера здесь не предполагается. Обработчик не содержит фиксированного срока автоматического закрытия. Для общего восстановления используется ''DEFERRED_TICKET_RECHECK_SECONDS'', для сверки состава — ''INTERVAL_TIME_BD_REQ''.
-При долгом ожидании проверьте актуальный статус и ревизию Ticket, выбранную версию Python/workspace, настройку интервала, причину ожидания, наличие доступного внешнего действия и права пользователя. Затем — scoped API, ready/defer, XMPP и periodic reconciliation. Не считайте штатное ожидание внешнего решения зависанием только по тому, что Ticket не поменялся от очередного таймера.
+Порядок диагностики долгого ожидания:
+  - Прочитать актуальные статус и ревизию Ticket.
+  - Сверить выбранные Python/workspace с канонической генерацией.
+  - Проверить именованный интервал, локальную причину и момент готовности defer.
+  - Проверить доступность внешнего действия и права принимающего решение.
+  - Проверить scoped API, ready-очередь, XMPP и periodic reconciliation.
+Повтор таймера без изменения статуса штатен, пока внешнее решение не принято. Неопределённый ответ записи требует чтения сохранённого состояния перед повтором.
 ===== Проверенные источники =====