Различия

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

--- sharixopen:knowledge:scenarios:st_request_inprocess [2026/10/28 21:46] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:st_request_inprocess [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, dbsynce",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "ST_REQUEST",
+                "audience_developer",
-                "IN_PROCESS",
+                "audience_integrator",
-                "verification",
+                "audience_support",
-                "BPMN"
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_security_requirements",
+                "topic_handlers_blockly",
+                "st_request",
+                "ticket_in_process",
+                "verification_workflow",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "provenance",
+                "requirements"
             ]
         },
@@ Строка 169: / Строка 190: @@
                 "path": "lib/integration_ports.py",
                 "sha256": "d079ec56e6709b29d7755e47d2a88d423235fe8eb1bf7a92851ae25d74bf1066"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 192: / Строка 219: @@
             "utility": "tools/expand_bpmn_view_bounds.py",
             "utility_sha256": "f878658b0115773e34f6c3eec72eba5984d873e60d8e2a4336b3dfb2a8026d87"
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "integrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "handlers/support",
+                "security/requirements",
+                "handlers/blockly"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_integrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_support",
+                "topic_security_requirements",
+                "topic_handlers_blockly",
+                "st_request",
+                "ticket_in_process",
+                "verification_workflow",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python",
+                "provenance",
+                "requirements"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "Конкретизация шагов, участников, условий, результатов и диагностики; перечисления; BPMN сохранены побайтово",
+            "current_source_records_verified": 23,
+            "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": "60994fbb72587be5a10e0aa07510ee3446c8dc7cd56298460471887ed6687d03",
+    "content_sha256": "82b312aaaadefb1e5d8f9d650327088b0327bfd6489c4ad6fee60c61cb29d93f",
     "schema": 1
 }
@@ Строка 201: / Строка 282: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_st_request_inprocess'', тип ''ST_REQUEST'' (1), рабочий статус ''IN_PROCESS''. Описана опубликованная встроенная реализация и изученные внешние контракты на 28.10.2026. Сгенерированный Python побайтово совпадает с результатом канонического renderer Blockly workspace. Выбранная версия на конкретной установке, её настройки и доступность API/XMPP проверяются отдельно.
+**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#integrator|Интегратор]] · [[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_inprocess'', тип ''ST_REQUEST'' (1), рабочий статус ''IN_PROCESS''. 31.10.2026 исходники повторно получены из Git: обе Python-копии совпали с новой канонической генерацией Blockly, проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранная серверная версия, её настройки и работающие API/XMPP проверяются отдельно.
 ===== Назначение и границы =====
-Обработчик сопровождает обращение на стадии выполнения. Сначала он проверяет рабочий статус, затем стабильный контракт в ''Ticket.json''. Контракты ''document-verification-v1'' и ''requirement-check-v1'' идут в профильный workflow **до проверки** ''STREQ_AUTOACCEPT''. При REST-снимке контракт читается непосредственно из metadata; при первоначальном XMPP-конверте учитывается вложенное поле ''json''. Название карточки не определяет её контракт.
+Обработчик сопровождает обращение на стадии выполнения. Порядок выбора ветви:
+  - Проверить, что локальный снимок имеет рабочий статус IN_PROCESS.
+  - Прочитать стабильный контракт из Ticket.json: document-verification-v1 или requirement-check-v1.
+  - Для профильного контракта вызвать организацию проверки и advance; до STREQ_AUTOACCEPT эта ветвь не доходит.
+  - Для обычного обращения использовать STREQ_AUTOACCEPT: ожидать действия пользователя либо запросить DONE.
+В REST-снимке контракт читается непосредственно из metadata, в первоначальном XMPP-конверте учитывается вложенное поле json. Заголовок обращения не определяет контракт.
+Результат зависит от вида обращения:
-Для обычного обращения отключённый ''STREQ_AUTOACCEPT'' означает ожидание работы пользователя, включённый — запрос перехода в ''DONE''. Сам обработчик не исполняет текст обращения, не доказывает устранение проблемы и не выполняет ручную проверку. Для профильных контрактов autoaccept не заменяет решение проверяющего или доменную политику результата.
+  * **Обычное, STREQ_AUTOACCEPT выключен:** ожидание работы пользователя.
+  * **Обычное, STREQ_AUTOACCEPT включён:** запрос DONE; содержание обращения при этом не исполняется и исправление проблемы не доказывается.
+  * **Профильная проверка:** решение определяется состоянием документа/попытки проверки и доменными правилами; autoaccept не заменяет проверяющего.
 End event на схемах завершает показанный проход или операцию. Все процессы помечены ''isExecutable=false'': просмотрщик Wiki их не запускает. Runtime исполняет выбранный проверенный Python, полученный из Blockly; XML BPMN служит описанием реализации.
@@ Строка 1046: / Строка 1146: @@
 ==== Проверка документа ====
-Для ''document-verification-v1'' вызов ''advance'' возвращает ''manual_required'' и первоначальные уведомления. Он не создаёт ''DocumentVersion'' и не подтверждает документ автоматически. Решение вносит пользователь с соответствующим доступом. Применение результата, проверка ожидаемой редакции документа и дальнейшее закрытие принадлежат следующему ''DONE''/''WONTFIX'' workflow.
+Для document-verification-v1:
+  * advance возвращает manual_required и первоначальные уведомления;
+  * новая DocumentVersion не создаётся этим вызовом;
+  * проверяющий вносит решение через доступный интерфейс;
+  * ожидаемая редакция документа и применение результата проверяются отдельным DONE/WONTFIX workflow.
+Наличие уведомления или статус IN_PROCESS не означают, что документ подтверждён.
 ==== Проверка требования ====
@@ Строка 1061: / Строка 1168: @@
 ===== Организация встречи не является результатом проверки =====
-Примитив ''prepare_verification_organization'' действует только для ''requirement-check-v1''; для проверки документа он ничего не меняет. Он вызывает действие ''organize'' и публичный интеграционный порт подготовки встречи. Отсутствие подключённого провайдера или ответ ''available=false'' не блокирует последующий ''advance'' и не означает отрицательную проверку.
+Подготовка организации проверки выполняется явно перед advance:
+  * **document-verification-v1:** примитив ничего не меняет.
+  * **requirement-check-v1:** вызывается organize и публичный интеграционный порт подготовки встречи.
+  * **Провайдер не подключён либо available=false:** advance всё равно продолжается; это не отрицательный результат проверки.
+При доступной организации сохраняются:
+  * booking в RequirementCheck.organization_data;
+  * организационные данные в Ticket.json.organization;
+  * при отсутствии активной записи — уведомление автору о self-booking URL, если оно предусмотрено;
+  * уведомление проверяющим об assignment URL, если оно предусмотрено.
-При доступной организации backend сохраняет сведения о booking в ''RequirementCheck.organization_data'' и ''Ticket.json.organization''. Если активной записи ещё нет, наличие self-booking URL может породить уведомление автору, а assignment URL — уведомление проверяющим. Этот шаг не меняет результат ''RequirementCheck''. Наличие ссылки не доказывает, что пользователь записался, встреча состоялась или проверка пройдена.
+Это организация встречи, а не изменение результата RequirementCheck. Ссылка не доказывает запись, состоявшуюся встречу или успешную проверку.
 Ошибка HTTP/разбора ответа ''organize'' логируется; проход продолжается с ''advance''. Ошибка отправки уведомления вне этого локального catch может попасть в общий retry. Внутреннее устройство необязательного провайдера встреч здесь не описывается: закреплён именно публичный порт backend.
@@ Строка 1279: / Строка 1397: @@
 </sharix-bpmn>
-Пользователь открывает карточку Ticket и выбирает допустимый переход. Форма профильной проверки позволяет передать комментарий и, для ''requirement-check-v1'', применимые баллы. View сохраняет metadata результата вместе с разрешённой сменой статуса в atomic-секции. Это запись решения для последующего потребителя; сама форма не импортирует dbsynce и не применяет доменный результат напрямую.
+Ручной результат вносится через карточку Ticket:
+  - Пользователь выбирает доступный DONE либо WONTFIX.
+  - Передаёт комментарий; для requirement-check-v1 при необходимости указывает применимые баллы.
+  - View проверяет разрешение перехода и в atomic-секции сохраняет metadata результата вместе со сменой статуса.
+  - Следующий профильный handler применяет доменный результат.
+Форма Tickets не импортирует dbsynce и не подтверждает проверку сама. Произвольный API-клиент может не сохранять поля результата так же, как эта форма.
 Чтение Ticket и право менять его статус проверяются отдельно. Авторство само по себе не даёт право менять статус; учитываются права управления Ticket и доступные переходы. Связанные с заказом Ticket не должны обходить lifecycle заказа через универсальную форму. Наличие API для смены статуса не доказывает, что произвольный API-клиент сохраняет все поля ручной проверки так же, как эта форма.
@@ Строка 1288: / Строка 1413: @@
 ===== Уведомления и подтверждение отправки =====
-Backend возвращает audience, текст и ключ уведомления. Runtime получает JID автора через защищённый API; получатели ''reviewers'' — активные участники группы списка Ticket, полученные через отдельный защищённый endpoint. Повторяющиеся JID убираются. При наличии фактической попытки отправки сохраняется ''ack_notification'' для ключа; уже подтверждённые ключи backend не возвращает.
+Для уведомления backend возвращает audience, текст и ключ:
+  * **creator:** runtime получает JID автора через защищённый API.
+  * **reviewers:** JID активных участников группы списка Ticket возвращает отдельный защищённый endpoint; повторяющиеся адреса исключаются.
+  * **Подтверждение:** после фактической попытки отправки runtime вызывает ack_notification для ключа; подтверждённые ключи backend больше не возвращает.
+Если получателя нет, доставка не подтверждается. Членство в списке получателей не выдаёт прав на Ticket.
 Это защита от обычных повторных отправок, а не гарантия exactly-once или прочтения человеком. Ошибка сохранения ack после отправки может привести к повтору уведомления. Отсутствие получателя не превращается в подтверждённую доставку. Сообщение проверяющему не выдаёт ему права на Ticket и не заменяет его решение.