| |
| sharixopen:knowledge:scenarios:st_request_done [2026/10/28 19:19] – [sharixknowledge] approved package sx_knowledge_api_open | sharixopen:knowledge:scenarios:st_request_done [2026/10/31 14:26] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open |
|---|
| "ShariXKnowledgeOpenKnowledgeOperationsRuntimehealth", | "ShariXKnowledgeOpenKnowledgeOperationsRuntimehealth", |
| "ShariXKnowledgeScenarios" | "ShariXKnowledgeScenarios" |
| | ], |
| | "depends_on": [ |
| | "ShariXKnowledgeOpenKnowledgeModulesHandlers", |
| | "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce" |
| | ], |
| | "verified_by": [ |
| | "ShariXKnowledgeVerification" |
| ] | ] |
| }, | }, |
| "domain": "business_processes", | "domain": "business_processes", |
| "lifecycle": "implemented", | "lifecycle": "implemented", |
| "component": "handlers", | "component": "handlers_examples, handlers_backend, tickets, dbsynce", |
| "parents": [ | "parents": [ |
| "ShariXKnowledgeScenarios" | "ShariXKnowledgeScenarios" |
| ], | ], |
| "terms": [ | "terms": [ |
| "ST_REQUEST", | "audience_developer", |
| "DONE", | "audience_integrator", |
| "DocumentVersion", | "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_done", |
| | "verification_workflow", |
| | "requirement_check", |
| | "document_version", |
| | "verification_completed", |
| | "notification_ack", |
| | "bpmn", |
| | "ticket", |
| | "blockly", |
| | "generated_python" |
| ] | ] |
| }, | }, |
| "path": "lib/activation.py", | "path": "lib/activation.py", |
| "sha256": "f78d4e219a5b83c7952bd366a4e7a711589b1d382af653a0c453c0524e4220f7" | "sha256": "f78d4e219a5b83c7952bd366a4e7a711589b1d382af653a0c453c0524e4220f7" |
| | }, |
| | { |
| | "repository": "sharix-open-tickets", |
| | "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14", |
| | "path": "models/ticket.py", |
| | "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43" |
| } | } |
| ], | ], |
| "complete": "2a776584735b60aa745eec11fbb27260dec2907abce0de21221a9dbdb0fd6385" | "complete": "2a776584735b60aa745eec11fbb27260dec2907abce0de21221a9dbdb0fd6385" |
| } | } |
| | }, |
| | "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_done", |
| | "verification_workflow", |
| | "requirement_check", |
| | "document_version", |
| | "verification_completed", |
| | "notification_ack", |
| | "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": 23, |
| | "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence", |
| | "canonical_regeneration": { |
| | "kind": "ticket", |
| | "compared_python_paths": [ |
| | "handlers/open_st_request_done.py", |
| | "generated_handlers/open_st_request_done.py" |
| | ], |
| | "generator_sources_verified": 11, |
| | "handler_executed": false |
| | }, |
| | "runtime_checked": false |
| } | } |
| }, | }, |
| "content_sha256": "8fa8a384acc4252e52818581c0baf803e5a90505024446e76e491879f8968a25", | "content_sha256": "6f3ca23bd4a1e1d21027e966364d3e3a2d67d4101f56aeb0146a87093d4f33dd", |
| "schema": 1 | "schema": 1 |
| } | } |
| ~~NOCACHE~~ | ~~NOCACHE~~ |
| |
| **Область:** ShariX Open. **Обработчик:** ''open_st_request_done'', тип ''ST_REQUEST'' (1), рабочий статус ''DONE'' (141). Текущая встроенная реализация изучена по опубликованному Git на 28.10.2026; Python побайтово сверен с каноническим renderer Blockly workspace. На сервере отдельно проверяются выбранная версия и доступность runtime/API. | **Назначение:** [[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_done'', тип ''ST_REQUEST'' (1), рабочий статус ''DONE'' (141). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия и работающая установка проверяются отдельно. |
| |
| ===== Назначение и границы ===== | ===== Назначение и границы ===== |
| ''DONE'' — стадия Ticket, а не универсальное доказательство успешного завершения всего процесса. Для обычного обращения обработчик ждёт подтверждения закрытия. Для стабильных контрактов ''document-verification-v1'' и ''requirement-check-v1'' он вызывает backend ''complete'', отправляет итоговое уведомление и запрашивает ''CLOSED''. В этом handler нет развилки по ''STREQ_AUTOACCEPT'' и нет автоматического закрытия обычной заявки по истечении таймера. | DONE — стадия Ticket. Дальнейшее поведение зависит от контракта: |
| | |
| | * **Обычное обращение:** ждать отдельного подтверждения закрытия. |
| | * **document-verification-v1 / requirement-check-v1:** вызвать backend complete, отправить итоговое уведомление и запросить CLOSED. |
| | |
| | STREQ_AUTOACCEPT здесь не используется; таймер обычной заявки не выбирает решение за пользователя. |
| |
| Просмотрщик Wiki показывает описание, а не исполняет обработчик. Схемы помечены ''isExecutable=false''; runtime исполняет выбранный проверенный Python, сгенерированный из Blockly. End event завершает конкретный проход, а не объявляет успех всех связанных требований. | Просмотрщик Wiki показывает описание, а не исполняет обработчик. Схемы помечены ''isExecutable=false''; runtime исполняет выбранный проверенный Python, сгенерированный из Blockly. End event завершает конкретный проход, а не объявляет успех всех связанных требований. |
| </sharix-bpmn> | </sharix-bpmn> |
| |
| Backend хранит доменный результат отдельно от статуса Ticket. При первом вызове он требует ''DONE'' или ''WONTFIX'', получает metadata ручного результата и выбирает actor: явно переданный actor, иначе существующий пользователь ''reviewer_user_id'', иначе ''assigned_to''. Штатный вызов handler API явного actor не передаёт. Это выбор источника атрибуции; он не выдаёт пользователю новые права. | Первое профильное завершение в backend: |
| | |
| | - Проверить DONE либо WONTFIX. |
| | - Получить metadata ручного результата. |
| | - Определить actor: явный аргумент, затем существующий reviewer_user_id, затем assigned_to. |
| | - Применить доменный результат отдельно от статуса Ticket. |
| | |
| | Handler API явный actor не передаёт. Атрибуция результата не выдаёт новые права. |
| |
| ==== Документ ==== | ==== Документ ==== |
| Для ''document-verification-v1'' в ''DONE'' backend находит документ по public id и создаёт проверенную ''DocumentVersion''. Проверяются соответствие документа Ticket, точная ''draft_revision'' и совместимость identity с уже проверенной версией. Изменившийся после запроса черновик отклоняется: требуется новая заявка проверки, а не подтверждение старой редакции. | Для ''document-verification-v1'' в ''DONE'' backend находит документ по public id и создаёт проверенную ''DocumentVersion''. Проверяются соответствие документа Ticket, точная ''draft_revision'' и совместимость identity с уже проверенной версией. Изменившийся после запроса черновик отклоняется: требуется новая заявка проверки, а не подтверждение старой редакции. |
| |
| В версию входят структурированные данные, срок действия, уровень/источник проверки, actor, ссылка на Ticket и снимки файлов. Обновляется указатель на текущую проверенную версию; планируется синхронизация документа. Сохранение формы Ticket само по себе этих действий не выполняет. | В проверенную DocumentVersion входят: |
| | |
| | * структурированные данные и снимки файлов; |
| | * срок действия; |
| | * уровень и источник проверки; |
| | * actor и ссылка на Ticket. |
| | |
| | Затем обновляется указатель текущей проверенной версии и планируется синхронизация документа. Сохранение формы Ticket само этого не делает. |
| |
| ==== RequirementCheck ==== | ==== RequirementCheck ==== |
| Для ''requirement-check-v1'' backend загружает связанную попытку. Если она ''PENDING'', вызывается доменное применение результата с ''passed=True'', actor, комментарием и применимыми баллами. Проверяются связь с попыткой, возможность завершить её, обязательный ответственный и правила результата. Для уже завершённой попытки в ''DONE'' допустим только ''PASSED''; несовместимое терминальное состояние приводит к ошибке. | Для requirement-check-v1: |
| | |
| | * загрузить связанную попытку; |
| | * у PENDING применить passed=True, actor, комментарий и применимые баллы через доменную операцию; |
| | * проверить связь, допустимость завершения, обязательного ответственного и правила результата; |
| | * для уже завершённой попытки требовать PASSED, иначе вернуть ошибку. |
| |
| Есть существенная граница текущей реализации: у автоматического алгоритма, использующего баллы и минимальный порог, положительное ''passed=True'' не отменяет порог. Низкий результат может сохранить ''FAILED'', хотя Ticket пришёл в ''DONE''. После первого применения backend возвращает фактический outcome; runtime всё равно переходит к ''CLOSED'' после успешного ответа. Поэтому надпись ''DONE'' или ''CLOSED'' не заменяет проверку outcome и состояния ''RequirementCheck''. В схеме это отражено как доменная политика результата, а не как безусловное «DONE → PASSED». | Есть существенная граница текущей реализации: у автоматического алгоритма, использующего баллы и минимальный порог, положительное ''passed=True'' не отменяет порог. Низкий результат может сохранить ''FAILED'', хотя Ticket пришёл в ''DONE''. После первого применения backend возвращает фактический outcome; runtime всё равно переходит к ''CLOSED'' после успешного ответа. Поэтому надпись ''DONE'' или ''CLOSED'' не заменяет проверку outcome и состояния ''RequirementCheck''. В схеме это отражено как доменная политика результата, а не как безусловное «DONE → PASSED». |
| |
| ==== Потребители и активация ==== | ==== Потребители и активация ==== |
| После применения результата backend собирает найденных потребителей из reason проверки либо области документа, убирает повторы и вызывает ''evaluate_requirements''. Для каждого потребителя с ''ok=true'' вызывается ''resume_approved_activation''. | Пересчёт потребителей: |
| | |
| | - Собрать найденных потребителей из reason проверки либо области документа. |
| | - Исключить повторы. |
| | - Вызвать evaluate_requirements для каждого. |
| | - При ok=true вызвать resume_approved_activation. |
| | |
| | Это возобновление ранее одобренного процесса; выполнение одной проверки не отменяет остальные требования. |
| |
| Это возобновление ранее одобренного процесса. Для ''ACCESS_REQUEST''/''NEG_REQUEST'' оно будит текущий handler, оставляя решение в его Blockly-алгоритме. Для исторической активации через ''ST_REQUEST'' допускается повтор канонического gate при ''DONE''/''CLOSED''. Завершение одной проверки не выдаёт новое одобрение и не обходит оставшиеся обязательные требования. | Это возобновление ранее одобренного процесса. Для ''ACCESS_REQUEST''/''NEG_REQUEST'' оно будит текущий handler, оставляя решение в его Blockly-алгоритме. Для исторической активации через ''ST_REQUEST'' допускается повтор канонического gate при ''DONE''/''CLOSED''. Завершение одной проверки не выдаёт новое одобрение и не обходит оставшиеся обязательные требования. |
| Если marker ''verification_runtime.completed'' уже сохранён, backend возвращает записанные outcome/details и ещё не подтверждённое итоговое уведомление. Повторное создание версии документа, применение результата и пересчёт потребителей в этой ветви не выполняются. Это идемпотентность по marker конкретного Ticket, а не разрешение автоматически пересмотреть прежнее решение после переоткрытия. | Если marker ''verification_runtime.completed'' уже сохранён, backend возвращает записанные outcome/details и ещё не подтверждённое итоговое уведомление. Повторное создание версии документа, применение результата и пересчёт потребителей в этой ветви не выполняются. Это идемпотентность по marker конкретного Ticket, а не разрешение автоматически пересмотреть прежнее решение после переоткрытия. |
| |
| Между ''complete'', уведомлением и сменой статуса в ''CLOSED'' нет одной общей транзакции. При потере ответа backend мог уже сохранить результат, а Ticket ещё оставаться в ''DONE''. Последующий проход использует marker; нельзя считать ошибку HTTP доказательством того, что результата нет. Если требуется новая попытка проверки, её следует оформлять по доменному сценарию с учётом редакции/попытки, а не стирать marker ради повторного исполнения. | При неопределённом результате различать: |
| | |
| | * backend уже мог сохранить complete и marker; |
| | * Ticket ещё может оставаться DONE; |
| | * уведомление могло уйти без сохранённого ack; |
| | * CLOSED — отдельный запрос. |
| | |
| | Общей транзакции этой последовательности нет. Сначала перечитать состояние; HTTP-ошибка не доказывает отсутствие результата. Для новой проверки оформляют доменную попытку/редакцию, а не стирают marker. |
| |
| ===== Внешнее действие для обычного обращения ===== | ===== Внешнее действие для обычного обращения ===== |
| |
| ===== Диагностика ===== | ===== Диагностика ===== |
| Для зависшего профильного Ticket различайте: статус Ticket, состояние документа/попытки, marker ''completed'', outcome, consumer evaluations, ack уведомления и переход в ''CLOSED''. Проверьте, не изменился ли черновик, не конфликтует ли терминальное состояние попытки с Ticket, хватает ли ответственного/баллов и работает ли scoped API. Для обычного обращения ожидание подтверждения закрытия является штатным поведением. | Диагностика профильного DONE: |
| | |
| | - Сверить статус Ticket и состояние документа/попытки. |
| | - Проверить draft_revision и совместимость терминального состояния. |
| | - Прочитать marker completed, outcome и consumer_evaluations. |
| | - Сверить ответственного, применимые баллы и scoped API. |
| | - Отдельно проверить ack и переход CLOSED. |
| | |
| | Для обычного обращения ожидание подтверждения закрытия штатно. Для профильного DONE/CLOSED сами по себе не доказывают положительный outcome или готовность всех потребителей. |
| |
| ===== Проверенные источники ===== | ===== Проверенные источники ===== |
