Различия

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

--- sharixopen:knowledge:scenarios:report_handler [2026/10/28 21:35] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:report_handler [2026/10/31 14:26] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 13: / Строка 13: @@
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
     "extensions": {
         "taxonomy": {
-            "domain": "business_processes",
+            "domain": "operations",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "XMPP",
+                "audience_developer",
-                "reports",
+                "audience_operator",
-                "first-party",
+                "audience_administrator",
-                "BPMN"
+                "audience_support",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_operations_diagnostics",
+                "topic_handlers_blockly",
+                "topic_handlers_runtime",
+                "first_party_handler",
+                "xmpp",
+                "handler_reports",
+                "bpmn",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 111: / Строка 129: @@
                 "aggregate_handler_reports"
             ]
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "operator",
+                "administrator",
+                "support",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "operations/diagnostics",
+                "handlers/blockly",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_operator",
+                "audience_administrator",
+                "audience_support",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_operations_diagnostics",
+                "topic_handlers_blockly",
+                "topic_handlers_runtime",
+                "first_party_handler",
+                "xmpp",
+                "handler_reports",
+                "bpmn",
+                "blockly",
+                "generated_python"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "Конкретизация действий, условий, результатов и диагностики; перечисления; исходные BPMN сохранены",
+            "current_source_records_verified": 10,
+            "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "kind": "first_party",
+                "compared_python_paths": [
+                    "handlers/open_report_handler.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "c25dde4b69cce3c96bcd0ecb35132018efa4ef07c0ebbe488bbe8c95d347baa7",
+    "content_sha256": "3ca60e6210baf10cc92f0d9a5470122c77c819a2f4b52f4217e29f4680e93204",
     "schema": 1
 }
@@ Строка 120: / Строка 192: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_report_handler'', системный first-party handler без типа/рабочего статуса Ticket. Проверено 29.10.2026: опубликованный Python побайтово совпадает с каноническим first-party Blockly renderer. Фактические runtime config, версия и XMPP-состояние установки проверяются отдельно.
+**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#operator_razvjortyvanija|Оператор развёртывания]] · [[sharixopen:knowledge:classification:audiences#administrator|Администратор]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#diagnostika|Эксплуатация → Диагностика]] · [[sharixopen:knowledge:classification:topics#blockly|Обработчики → Blockly]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_report_handler'', системный first-party handler без типа/рабочего статуса Ticket. 31.10.2026 исходники повторно получены из Git. First-party Python совпал с каноническим renderer; отдельно проверены операция aggregate_handler_reports и общий launcher. Сам обработчик и его внешние действия не запускались. Выбранная версия и работающая установка проверяются отдельно.
 ===== Назначение и канонический контракт =====
-Бот принимает разрешённые XMPP-тексты, группирует их по отправителю в памяти и периодически пересылает сводку техническому получателю. Это не постоянный журнал ошибок, не очередь задач Deck, не редакторское согласование и не гарантированная доставка каждому сотруднику.
+Сборщик выполняет две независимые части:
+  * входящий callback добавляет разрешённые XMPP-тексты в память по отправителю;
+  * длительный цикл периодически пересылает сводку техническому адресату.
+Это не постоянный журнал ошибок, очередь Deck или редакторское согласование. Доставка каждому сотруднику не реализована.
 В Blockly зафиксирована typed operation ''aggregate_handler_reports''. Сгенерированный Python вызывает binding; runtime сверяет точную последовательность с каталогом builtin и загружает ''first_party_operations/open_report_handler.py''. При несовпадении контракт отклоняется. В runtime исполняется Python; Blockly JSON не интерпретируется. Код operation и общий launcher включены в закреплённые источники, поскольку wrapper сам по себе не описывает фильтры, память и ошибки пересылки.
@@ Строка 254: / Строка 339: @@
 </sharix-bpmn>
-Callback принимает только chat/normal. Resource отбрасывается, sender bare JID сопоставляется с listen_to: handler ids из каталога, кроме самого open_report_handler, плюс технический UID 5101 в настроенном EJ_HOST. Состав каталога может включать материализованные contributions установки; произвольный внешний JID не становится разрешённым только из-за текста «ошибка».
+Входной фильтр:
-Body проверяется на None. При допуске строка добавляется в список отправителя под lock, затем пишется лог recorded. Callback не разбирает severity/JSON, не выполняет команды из текста и не изменяет Ticket. Сообщения не дедуплицируются по event id: повторная доставка может стать ещё одной строкой отчёта.
+  - Пропустить только chat/normal.
+  - Отбросить resource и получить bare JID.
+  - Сверить его с listen_to: handler ids каталога без самого open_report_handler и технический UID 5101 в EJ_HOST.
+  - Пропустить body, отличный от None.
+Каталог может включать материализованные contributions установки. Произвольный JID не становится разрешённым из-за слова «ошибка» в тексте.
+После допуска сообщения:
+  - Под lock добавить строку в список отправителя.
+  - Записать лог recorded.
+  - Позднее включить строку в snapshot сводки.
+Callback не разбирает severity/JSON, не выполняет команды и не меняет Ticket. Event-id дедупликации нет; повторная доставка может стать ещё одной строкой.
 Буфер — process memory. Он не хранится в БД или durable outbox; рестарт способен потерять неотправленное. Лог recorded подтверждает запись в локальную память текущего процесса, не пересылку получателю.
@@ Строка 466: / Строка 564: @@
 </sharix-bpmn>
-После общего XMPP connection preflight start_handler сразу начинает цикл, а не сначала ждёт полный интервал. На каждой итерации проверяется exit_event, под lock снимается копия reports и исходный буфер очищается. Новые сообщения во время отправки накапливаются отдельно.
+Итерация отправки после XMPP connection preflight:
-Непустой snapshot форматируется по JID со списками сообщений. Сводка отправляется как XMPP chat каждому proceed_to, кроме собственного JID. В текущей operation proceed_to содержит **фиксированный UID 5101** в EJ_HOST. Это не автоматически вычисляемая METASERVICE-ADMIN/staff-группа, не Ticket.group и не все создатели исходных сообщений. Изменение адресата требует изменения соответствующего контракта/конфигурации, а не правки схемы Wiki.
+  - Проверить exit_event.
+  - Под lock снять копию reports и очистить исходный буфер.
+  - Пока snapshot отправляется, принимать новые сообщения в отдельный текущий буфер.
+  - При непустом snapshot сформировать и отправить сводку.
-Флаг delivered становится true, когда хотя бы один send-call вернулся без исключения. Это не receipt и не прочтение. Если ни одной такой отправки нет, snapshot под lock возвращается **в начало** текущих списков: более ранние сообщения сохраняются перед прибывшими во время попытки. Если send хотя бы одному адресату успешен, snapshot не восстанавливается для остальных. При нынешнем единственном получателе это один исход; при будущем расширении списка нельзя считать механизм индивидуальным durable retry для каждого адресата.
+Первая итерация начинается сразу; полный INTERVAL_TIME_REPORT до неё не ожидается.
+Отправка сводки:
+  * формат — JID и списки сообщений;
+  * транспорт — XMPP chat;
+  * получатели — proceed_to без собственного JID;
+  * в текущей operation единственный адресат — фиксированный 5101@EJ_HOST.
+Этот адресат не вычисляется из METASERVICE-ADMIN/staff, Ticket.group или авторов сообщений. Изменение получателя требует правки соответствующего контракта/конфигурации.
+Результат send обрабатывается так:
+  * хотя бы один вызов без исключения устанавливает delivered=true;
+  * если таких вызовов нет, snapshot под lock возвращается в начало текущих списков перед новыми сообщениями;
+  * при хотя бы одном успешном вызове snapshot для остальных адресатов не восстанавливается.
+Это не receipt и не прочтение. Сейчас адресат один; алгоритм не является индивидуальным durable retry для будущего списка получателей.
 После итерации выполняется ''exit_event.wait(INTERVAL_TIME_REPORT)''. Это прерываемое ожидание: сигнал остановки не обязан ждать весь интервал. Затем цикл повторяется. Пустой snapshot не порождает сообщение «No reports available»: отправка в start_handler выполняется только при непустом наборе, хотя formatter имеет такую строку для отдельного вызова.
@@ Строка 480: / Строка 598: @@
 ===== Диагностика =====
-Разделяйте сообщение отправителя, попадание в allowlist, добавление в reports, снятый snapshot, вызов send и фактическое получение. Для отсутствующего отчёта проверяйте тип и bare JID, актуальный каталог, время работы процесса и INTERVAL_TIME_REPORT, затем фиксированного адресата и XMPP-логи.
+Порядок диагностики:
+  - Проверить тип сообщения и bare JID по актуальному allowlist.
+  - Подтвердить добавление в reports, учитывая время жизни процесса.
+  - Найти снятый snapshot и момент итерации INTERVAL_TIME_REPORT.
+  - Проверить фиксированного адресата и исход send.
+  - Отдельно подтвердить фактическое получение.
+Лог recorded относится к локальной памяти, а наличие строк в файловом журнале другого handler не доказывает отправки агрегатору.
 Успешный запуск общего runtime ещё не доказывает, что каждый handler отправляет отчёты в этот JID. Наличие сообщений в обычных файловых логах также не означает, что они были отправлены агрегатору. Для надёжного архива нужны предусмотренные системы журналирования; этот handler не заменяет их.