Различия

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

--- sharixopen:knowledge:scenarios:st_request_wontfix [2026/10/28 19:23] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:st_request_wontfix [2026/10/31 12:14] (текущий) – [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, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "ST_REQUEST",
+                "audience_developer",
-                "WONTFIX",
+                "audience_support",
-                "RequirementCheck",
+                "audience_reviewer",
-                "BPMN"
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_security_requirements",
+                "topic_handlers_blockly",
+                "st_request",
+                "ticket_wontfix",
+                "requirement_check",
+                "verification_workflow",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 182: / Строка 201: @@
                 "complete": "64e14afe814c90d92e630b6a861ee915caacf371934eff683996c2fa0aeea502"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "handlers/support",
+                "security/requirements",
+                "handlers/blockly"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_security_requirements",
+                "topic_handlers_blockly",
+                "st_request",
+                "ticket_wontfix",
+                "requirement_check",
+                "verification_workflow",
+                "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": 22,
+            "original_source_evidence_recheck": "После git fetch все исходные SHA-256 совпали; source_evidence содержит текущие проверенные commits",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_st_request_wontfix.py",
+                    "generated_handlers/open_st_request_wontfix.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "9baef4abb61d46b3b386d94c917f162ac208ad3e3ad19ecccaec5df9848f1b3c",
+    "content_sha256": "ac76d35524d99e33e2cc9f664186a8b7fdf8802b4d7d3eb449844a8464519b91",
     "schema": 1
 }
@@ Строка 191: / Строка 265: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_st_request_wontfix'', тип ''ST_REQUEST'' (1), рабочий статус ''WONTFIX'' (149). Опубликованный встроенный Python на 28.10.2026 побайтово сверен с канонической генерацией из Blockly workspace. Выбор локальной версии и работоспособность конкретного runtime не выводятся из одной этой страницы.
+**Назначение:** [[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#trebovanija|Доступ → Требования]] · [[sharixopen:knowledge:classification:topics#blockly|Обработчики → Blockly]].
+**Область:** ShariX Open. **Обработчик:** ''open_st_request_wontfix'', тип ''ST_REQUEST'' (1), рабочий статус ''WONTFIX'' (149). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly. Сам обработчик и его внешние действия при анализе не запускались. Выбранная версия, настройки и работоспособность конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-Для обычной заявки ''WONTFIX'' фиксирует решение «не будет исправлено» и ожидает отдельного решения о закрытии. Сам обработчик не выбирает основание отказа, не добавляет объяснение в карточку и не закрывает такую заявку по таймеру. ''STREQ_AUTOACCEPT'' здесь не используется.
+Для обычной заявки WONTFIX:
+  * фиксирует уже принятое решение «не будет исправлено»;
+  * ожидает отдельного решения о закрытии;
+  * не выбирает основание отказа и не добавляет объяснение в карточку;
+  * не закрывает заявку по таймеру.
+STREQ_AUTOACCEPT здесь не используется.
+Для document-verification-v1 и requirement-check-v1 действует профильное завершение:
+  - Backend фиксирует отрицательный результат конкретной проверки.
+  - Пересчитывает связанных потребителей.
+  - Runtime отправляет итоговое уведомление.
+  - Отдельно запрашивает CLOSED.
-Для ''document-verification-v1'' и ''requirement-check-v1'' применяется профильное завершение: backend фиксирует отрицательный результат, пересчитывает потребителей, runtime отправляет итоговое уведомление и запрашивает ''CLOSED''. Это завершение конкретной проверки. Оно не означает глобальное удаление документов, отзыв всех прежних подтверждений или деактивацию связанных объектов.
+Это не глобальное удаление документов, отзыв всех прежних подтверждений или деактивация связанных объектов.
 Оба BPMN-процесса имеют ''isExecutable=false''. Это описание реализации, а не исполняемый workflow Wiki. Runtime выполняет выбранный проверенный Python из Blockly. End event завершает показанную операцию, а не утверждает успех всего продукта.
@@ Строка 874: / Строка 970: @@
 </sharix-bpmn>
-Операция ''complete'' на ''dbsynce/api/handler/ticket/{ticket_id}/verification/'' сначала проверяет сохранённый marker ''verification_runtime.completed''. Если результата ещё нет, требуется ''DONE'' или ''WONTFIX''. При ''WONTFIX'' выбирается отрицательный результат. Actor берётся из явного аргумента, иначе из существующего ''reviewer_user_id'' в metadata ручного результата, иначе из ''assigned_to''; handler API явный actor не передаёт.
+Complete на dbsynce/api/handler/ticket/{ticket_id}/verification/:
+  - Прочитать marker verification_runtime.completed.
+  - Если результата ещё нет — потребовать DONE либо WONTFIX. Для WONTFIX выбрать отрицательный результат.
+  - Определить actor: явный аргумент, затем reviewer_user_id ручного результата, затем assigned_to.
+  - Применить соответствующий контракт документа либо RequirementCheck.
+Handler API явный actor не передаёт. Повтор с marker имеет отдельное поведение, описанное ниже.
 ==== Отказ в проверке документа ====
@@ Строка 882: / Строка 985: @@
 ==== Отказ по RequirementCheck ====
-Для ''requirement-check-v1'' должна существовать связанная попытка. Если она ''PENDING'', backend применяет ''passed=False'', actor, комментарий и применимые поля баллов через доменную операцию. Проверяются связь с Ticket, допустимость завершения попытки и обязательный ответственный. Явный отрицательный результат не становится положительным из-за высокого балла.
+Для requirement-check-v1:
-Если попытка уже завершена, для Ticket в ''WONTFIX'' допускается только ''FAILED''. ''PASSED'' и иные несовместимые состояния вызывают ошибку; результат не перезаписывается простым повтором handler. Отсутствующая попытка также является ошибкой. Следует сверить Ticket и фактическую попытку, а не вручную приписывать успешный complete.
+  * связанная попытка должна существовать;
+  * у PENDING применяется passed=False, actor, комментарий и применимые поля баллов через доменную операцию;
+  * проверяются связь с Ticket, допустимость завершения попытки и обязательный ответственный.
+Высокий балл не превращает явный отрицательный результат в положительный.
+Если попытка уже завершена:
+  * **FAILED:** совместимо с WONTFIX.
+  * **PASSED или иное несовместимое состояние:** ошибка, прежний результат не перезаписывается.
+  * **Попытка отсутствует:** ошибка связи.
+Нужно сверить Ticket и фактическую попытку, а не считать complete успешным по самому запуску handler.
 ==== Пересчёт потребителей ====
@@ Строка 896: / Строка 1011: @@
 Повторный ''complete'' при сохранённом marker возвращает прежние outcome/details и ещё не подтверждённое уведомление. Результат и consumer evaluations заново не вычисляются. Поэтому marker — граница идемпотентности этого Ticket, а не команда пересмотреть ранее сохранённое решение после переоткрытия.
-Вызов backend, XMPP-уведомление и переход в ''CLOSED'' разделены. Ответ мог потеряться после сохранения результата; уведомление могло уйти без сохранения ack; ''CLOSED'' мог ещё не сохраниться. При диагностике сначала различайте и перечитывайте эти состояния. Не стирайте marker и не повторяйте отрицательное решение вслепую ради исправления транспортной ошибки.
+Частично выполненную последовательность разбирать по отдельным фактам:
+  * результат сохранён в backend, но ответ мог потеряться;
+  * уведомление отправлено, но ack мог не сохраниться;
+  * CLOSED мог ещё не сохраниться после успешного доменного результата.
+Сначала перечитать эти состояния. Стирание marker или повтор отрицательного решения вслепую не исправляют транспортную ошибку.
 ===== Внешнее решение для обычной заявки =====
@@ Строка 915: / Строка 1036: @@
 ===== Что различать при диагностике =====
-Проверьте контракт и выбранную версию handler, статус Ticket, состояние связанной попытки/документа, marker completed, outcome, consumer evaluations, ack и переход в ''CLOSED''. Для обычной заявки отсутствие автоматического закрытия штатно. Для профильной — несовместимое терминальное состояние требует разбора решения, а не только исправления сетевого подключения.
+При диагностике сверить:
+  - Контракт и выбранную версию handler.
+  - Статус Ticket и состояние связанной попытки/документа.
+  - Marker completed, outcome и consumer_evaluations.
+  - Ключ ack уведомления.
+  - Отдельный результат перехода CLOSED.
+Для обычной заявки ожидание решения штатно. Для профильной несовместимый терминальный результат требует разбора решения, а не только сетевой проверки.
 ===== Проверенные источники =====