Различия

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

--- sharixopen:knowledge:scenarios:st_request_duplicate [2026/10/28 21:46] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:st_request_duplicate [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",
-                "DUPLICATE",
+                "audience_support",
-                "BPMN"
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_handlers_runtime",
+                "st_request",
+                "ticket_duplicate",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 114: / Строка 131: @@
                 "path": "services/handler_wakeup.py",
                 "sha256": "c9fdc62a18301fd7c075395c697d5b1c738c77713aa71fcbb5ab097e173d98de"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 138: / Строка 161: @@
             "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_duplicate",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
+            ],
+            "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": "4d5116f42b33055593b555aba8fdc0320ea01dce18de7a976286d94df6f89ea4",
+    "content_sha256": "62a3c1335c36a3783043876a02712620d37e489ddcfc8569a4e3c7525744d41a",
     "schema": 1
 }
@@ Строка 147: / Строка 217: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_st_request_duplicate'', тип ''ST_REQUEST'' (1), рабочий статус ''DUPLICATE'' (159). Опубликованная встроенная реализация изучена на 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_duplicate'', тип ''ST_REQUEST'' (1), рабочий статус ''DUPLICATE'' (159). 31.10.2026 исходники повторно получены из Git: обе Python-копии совпали с новой канонической генерацией Blockly, проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранная серверная версия, её настройки и работающие API/XMPP проверяются отдельно.
 ===== Назначение и границы =====
-Обработчик получает Ticket, уже отмеченный как дубликат, и ждёт отдельного решения о закрытии. Он не ищет похожие заявки, не выбирает основную карточку, не переносит описание, комментарии или вложения и не объединяет доменные результаты. Наличие статуса ''DUPLICATE'' не доказывает сохранность содержания в другой заявке.
+Вход — Ticket, которому уже назначен статус DUPLICATE. Обработчик:
+  * ждёт отдельного решения о закрытии;
+  * не ищет похожие заявки и не выбирает основную;
+  * не переносит описание, комментарии и вложения;
+  * не объединяет доменные результаты.
+Перед закрытием нужно проверить основную карточку и сохранение существенной информации. Статус DUPLICATE сам этого не подтверждает.
+До смены статуса пользователь:
+  - Открывает выбранную основную карточку.
+  - Сверяет описание, комментарии и вложения дубля с сохранёнными там сведениями.
+  - При необходимости вручную сохраняет существенную информацию в основной карточке.
+  - Затем принимает отдельное решение о закрытии дубля через доступный переход.
-Перед закрытием пользователь должен осмысленно проверить основную карточку и сохранение необходимой информации. Это действие вне текущего алгоритма; автоматического механизма слияния схема не приписывает. ''STREQ_AUTOACCEPT'' здесь не используется, автоматического закрытия по таймеру нет.
+STREQ_AUTOACCEPT здесь не используется; срока автоматического закрытия нет.
 Каноническое имя — ''open_st_request_duplicate''. Имя ''open_st_request_dublicate'' с исторической опечаткой присутствует только как legacy-запись каталога: ''builtin_available=false'', ''blockly_editable=false''. Оно не является второй исполняемой встроенной реализацией этого сценария; создавать ещё одну LDAP/XMPP-учётку на основании такой записи не требуется.
@@ Строка 378: / Строка 470: @@
 </sharix-bpmn>
-В своём рабочем статусе handler записывает локальную причину ''support_duplicate_closure'' и назначает повтор по ''ST_REQUEST_DUPLICATE_RECHECK_SECONDS''. Пустой reason в Blockly-примитиве defer использует уже сохранённую причину. Это состояние runtime и запись журнала, а не комментарий в Ticket и не уведомление пользователю.
+Один проход в своём рабочем статусе:
+  - Записать локальную причину support_duplicate_closure.
+  - Назначить defer по ST_REQUEST_DUPLICATE_RECHECK_SECONDS. Пустой reason использует ранее сохранённую причину.
+  - Завершить проход и освободить worker.
+Причина относится к runtime и журналу. Она не добавляет комментарий в Ticket и не уведомляет пользователя.
 Worker после прохода освобождается. Когда срок ''deferred_until'' наступает либо получена новая authoritative revision, Ticket становится готов к повторной проверке; одинаковый снимок не сбрасывает ожидание. Фактический запуск зависит от свободного worker и соединения XMPP. Defer хранится в памяти; после рестарта состав очереди сверяется с backend заново.
@@ Строка 579: / Строка 677: @@
 </sharix-bpmn>
-Пользователь должен иметь доступ к конкретному Ticket и право смены статуса. Авторство само по себе такого права не даёт. Канонические view/API проверяют объектный доступ и разрешённый переход lifecycle до сохранения; связанные с заказом Ticket не должны обходить жизненный цикл заказа через общую форму.
+Для внешнего решения проверяются отдельно:
-Из ''DUPLICATE'' текущий lifecycle разрешает только ''CLOSED''. Это закрытие существующего Ticket, а не удаление записи или перенос её содержимого. Прямого перехода в ''REOPENED'' из этой стадии в изученном lifecycle нет; схема его не предлагает.
+  * право чтения конкретного Ticket;
+  * право менять его статус;
+  * разрешённый переход текущего lifecycle;
+  * доменная граница: связанный заказ должен изменяться через действия заказа.
-После commit backend публикует события изменения владельца. ''ticket.moved'' направляется прежнему handler и исключает локальный снимок; если worker уже выполняется, применяется pending discard до его завершения. Для новой стадии с зарегистрированным handler предназначен ''ticket.changed''. Для ''CLOSED'' отдельного ''open_st_request_closed'' в каталоге нет.
+Авторство обращения само по себе не даёт права смены статуса.
+Для DUPLICATE текущий lifecycle содержит один исход:
+  * **CLOSED:** закрытие существующего Ticket.
+Закрытие не удаляет запись и не переносит содержимое. Прямого перехода DUPLICATE → 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-состояния.
@@ Строка 590: / Строка 704: @@
 Именованный интервал — ''ST_REQUEST_DUPLICATE_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.
+Повтор таймера без изменения статуса штатен, пока внешнее решение не принято. Неопределённый ответ записи требует чтения сохранённого состояния перед повтором.
 ===== Проверенные источники =====