Различия

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

--- sharixopen:knowledge:development:human_ai_handoff [2026/10/29 08:30] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:development:human_ai_handoff [2026/10/31 21:11] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 4: / Строка 4: @@
     "page": "sharixopen:knowledge:development:human_ai_handoff",
     "area": "open",
-    "type": "procedure",
+    "type": "policy",
-    "title": "Результат разработки для человека: автор, нейросеть и оператор",
+    "title": "Как подготовить изменение и инструкцию для оператора",
     "status": "review",
     "schema_version": 1,
@@ Строка 13: / Строка 13: @@
             "ShariXKnowledgeVerification",
             "ShariXKnowledgeOpenOperationsDeploy"
+        ],
+        "applies_to": [
+            "ShariXKnowledgeOpenKnowledgeDevelopmentPractice"
         ]
     },
     "extensions": {
         "taxonomy": {
-            "domain": "development",
+            "domain": "standards",
-            "lifecycle": "documented",
+            "lifecycle": "not_applicable",
             "parents": [
                 "ShariXKnowledgeMethodsStart"
             ],
-            "terms": []
+            "terms": [
+                "audience_developer",
+                "audience_operator",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "product_shared",
+                "material_policy",
+                "topic_development_delivery",
+                "topic_development_verification"
+            ],
+            "component": "ShariX Open"
         },
         "source_evidence": [
@@ Строка 206: / Строка 220: @@
             }
         ],
-        "reviewed_on": "2026-10-29"
+        "reviewed_on": "2026-10-29",
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "boundary_correction",
+            "public_boundary": "Публичная Wiki: ShariX Open и передача shared-изменения ответственному Platform. Внутренние действия Platform — intrawiki."
+        },
+        "editorial_source_check": {
+            "date": "2026-10-30",
+            "repository": "sharix-open-webapp-base",
+            "commit": "c19e6651449483d898f5ae33548f97c0ef7e1cd2",
+            "path": "bin/repositories.sh",
+            "sha256": "b763fdd351c71c6c6518253fba871efc7beb6f929badc54d863132fe7acea86e",
+            "finding": "update-* допускаются только при ASSEMBLY_KIND=open"
+        },
+        "license_boundary_review": {
+            "date": "2026-10-31",
+            "scope": "shared не является лицензией; публичная документация не раскрывает реализацию закрытых модулей",
+            "closed_modules_license_code": "sharix-proprietary-v1"
+        },
+        "list_format_review": {
+            "date": "2026-10-31",
+            "scope": "Перечисления полей, результатов и проверок оформлены списками; исходники, команды, таблицы, схемы и лицензионные границы сохранены."
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open",
+                "shared"
+            ],
+            "audiences": [
+                "developer",
+                "operator",
+                "reviewer",
+                "ai"
+            ],
+            "material": "policy",
+            "topics": [
+                "development/delivery",
+                "development/verification"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_operator",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "product_shared",
+                "material_policy",
+                "topic_development_delivery",
+                "topic_development_verification"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "lifecycle относится к описываемому коду, а status к редакции документа; implemented не означает успешный runtime тест"
+        },
+        "classification_review": {
+            "date": "2026-10-31",
+            "source": "Содержание текущей страницы и проверенный словарь классификации",
+            "body_scope": "classification_and_navigation_only"
+        },
+        "owner_clarification": {
+            "date": "2026-11-01",
+            "basis": "explicit owner instruction",
+            "scope": "disabled optional modules and immediate subject-documentation updates",
+            "runtime_claim": false
+        }
     },
-    "content_sha256": "b278fbe0de14d64a89d57550d93bc0105a95a79ea2e65b60a0770e2c9823e69f",
+    "content_sha256": "62ca90aaf5770d9b02fdf475582b0170744d91fda469864fee1996c74badabee",
     "schema": 1
 }
 </sharix-knowledge-meta>
-====== Результат разработки для человека: автор, нейросеть и оператор ======
+====== Как подготовить изменение и инструкцию для оператора ======
 ~~NOCACHE~~
-**Раздел:** [[sharixopen:knowledge:development:methodology:start|Методология разработки]]. **Назначение:** согласованный подход к подготовке и передаче изменений; это требование к работе автора, а не заявление о наличии автоматической системы внедрения.
+**Назначение:** [[sharixopen:knowledge:classification:materials#politika_i_pravila|Политика и правила]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]] · [[sharixopen:knowledge:classification:products#obschij_komponent|Общий компонент]].
-===== Для разработчика и оператора =====
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#operator_razvjortyvanija|Оператор развёртывания]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
-Начать с наблюдаемой проблемы и ожидаемого результата. Определить продукт, installation root, owners и текущие revisions, уже применённые этапы, затронутые данные и потребителей. Условия из старой карточки или расшифровки сверяются заново. Рабочие ветки и installed modules определяет конфигурация и статус репозиториев; отсутствие checkout не компенсируется похожим продуктом.
-Человек должен получить небольшой, цельный и проверяемый комплект: изменение, основание его применимости, полный сценарий применения и критерии результата. Для согласованных изменений ShariX Open/shared и Platform поставка разделяется по продуктам: общий код входит в root patch ShariX Open, Platform-owned адаптации — в её root patch. Shared на Platform приходит опубликованным Git commit, а не повторным применением первого patch. Если изменений для продукта нет, не создают пустой patch ради количества файлов. Самостоятельный внешний продукт, например Moodle plugin, имеет собственную базу и сценарий при наличии такого задания.
+**Темы:** [[sharixopen:knowledge:classification:topics#peredacha_izmenenij|Разработка → Передача изменений]] · [[sharixopen:knowledge:classification:topics#proverka|Разработка → Проверка]].
-^ Часть поставки ^ Что в ней необходимо ^
-| Изменение | Root patch с путями относительно installation root, перечень owners и точная исходная база каждого; зависимость от предыдущих этапов. |
-| Полный сценарий | Роли, подготовка и перенос файлов, точные каталоги/команды, preflight, dry-run, применение, source publication/pull, deploy/restart, приёмка, остановка и восстановление. |
-| Свидетельства | Реально выполненные команды и результаты, отдельно source-анализ, локальные и серверные проверки; невыполненные пункты и причина. |
-| Понятный итог | Как изменится действие пользователя, что увидит оператор при успехе и при существенных отказах, ограничения и необходимое решение владельца. |
-Сценарий помещается в тот же архив, что и patch, и доступен отдельной ссылкой. Один diff, многотомный набор промежуточных файлов или общий совет «обновите зависимости» не заменяют его. Не требуют распаковывать исходники поверх checkout и не создают второй installer. В командах указывают ''/tmp/ИМЯ.patch'', когда оператор разместит patch в ''/tmp''; автор не заявляет, что сам уже загрузил его на сервер.
-===== Для нейросети: контракт выдаваемого результата =====
+Человек, получающий исправление, должен понимать, какой файл взять, к какой версии он подходит, где выполнить команды и как определить результат. Подготовка патча заканчивается цельной поставкой:
-  - В начале установить scope и прочитать текущие README/CODING_POLICY/AGENTS владельцев и актуальные Wiki runbooks. Различать исходники продукта, shared и работающую установку; не выдавать название доски за достаточное доказательство.
-  - Проанализировать цепочку route → view/form/serializer → service/policy → модель/событие → consumer. Найти существующую функцию и библиотечный UI-элемент до создания нового. Не фиксировать только поверхностное совпадение имени.
-  - Сохранять единственного владельца бизнес-состояния. Для handlers сохранять typed Blockly → deterministic Python → provenance; учитывать внешние пользовательские действия, API, таймеры и доставку событий. BPMN — описание, не исполняемый источник runtime.
-  - Подготовить цельную поставку на проверенной базе. Дать человеку короткий маршрут: какой файл взять, где он должен лежать, из какого каталога и под какой ролью выполнить действия, что является успехом, когда остановиться.
-  - Явно перечислить «Выполнено автором», «Выполняет оператор», «Не проверено». Не писать «всё работает» по compile/import или по результату другого продукта. Не скрывать предупреждения и не выдавать запланированную миграцию за выполненную.
-  - Не угадывать SSH, systemd unit, секреты, актуальную ветку, базу данных и права пользователя. Неизвестное обозначать параметром с точным способом получения через штатную конфигурацию/runtime identity. Секреты не переносить в текст, логи и команды.
-  - Проверить инструкцию как последовательность человеческих действий: есть ли все входные файлы, не требует ли шаг результата, который ещё не создан, корректны ли пути и роли, понятно ли поведение после отказа. Ссылки на артефакты должны вести к реальным подготовленным файлам.
-Эти требования не дают дополнительных разрешений: подготовка patch, публикация Git, Wiki и внедрение на сервере — разные действия с собственным поручением. Необратимые или неавторизованные операции не скрывают внутри шага «проверка».
+  * сам патч;
+  * полный сценарий применения;
+  * сведения о выполненных проверках.
-===== Сценарий для подготовленного source patch =====
+Эта страница задаёт порядок передачи. Конкретная поставка должна содержать команды для своей базы и фактических каталогов. Установка приложения описана в [[sharixopen:knowledge:operations:deploy|отдельной процедуре]].
-Сначала прочитать [[sharixopen:knowledge:operations:deploy|актуальную процедуру установки ShariX Open]] и [[sharixopen:knowledge:development:upstream_update|публикацию owning repositories]]. Здесь фиксируется порядок передачи, а не универсальная команда для любого сервера.
-  - Зафиксировать backup/restore point для затронутых данных и согласовать окно, если требуется schema/data change. Проверить статус всех owners, отсутствие незавершённых Git операций и совпадение базы; отдельно учесть частично применённый прошлый этап.
+===== Что выяснить перед подготовкой =====
-  - Оператор переносит подготовленные файлы в ''/tmp''. Под назначенным deploy login переходит в фактический installation root. Для данного проекта последние подтверждённые пути — ''/opt/sharix-open-webapp-base'' и ''/opt/pre-sharix-platform-webapp-base''; другой путь подтверждается заново.
+  * Какая часть ShariX Open меняется: корневое приложение, отдельный модуль или общий (shared) компонент.
-  - Выполнить предусмотренный сценарием dry-run на точной базе. Применение multi-repository root patch должно учитывать самостоятельные owners: успешный dry-run только корневого Git не подтверждает файлы модулей. Не продолжать после failed hunk и не игнорировать ''.rej''; сверить фактические before/after и исправить поставку.
+  * Какие репозитории содержат изменение, их ветки и исходные commits.
-  - Проверить изменения, опубликовать согласованный набор owning repositories штатным ''repositories.sh''. При configured non-operational branch использовать документированный ''update-start → update-publish → update-finish''. Consumer получает опубликованный shared-код через Git; затем сверяет SHA.
+  * Какие предыдущие патчи уже применены и опубликованы. Не готовить повторное применение того же изменения.
-  - Выполнить точные дополнительные шаги данного изменения: необходимые миграции/переводы/static/env sync. Они должны быть названы в сценарии; не генерировать новые migrations автоматически на рабочем сервере.
+  * Какая установка будет обновляться, где она находится, какие данные и модули затрагиваются.
-  - Для уже подготовленного исходного состояния от deploy выполнить следующие фазы, останавливаясь при ошибке.
+  * Какие права нужны человеку для применения и какие действия выполнит администратор.
+Старую карточку и расшифровку сверяют с текущим кодом. Если нужного checkout нет, проверка похожего продукта не заменяет его. Сначала читают актуальные README, CODING_POLICY, AGENTS и инструкции Wiki относящихся к работе репозиториев.
+===== Что можно включать в публичную поставку =====
+Проверить LICENSE каждого репозитория и отметить отдельно:
+  * открыт ли код;
+  * является ли модуль общим;
+  * где он используется.
+Эти признаки не заменяют друг друга. Конструктор сервиса и другие отдельно лицензируемые закрытые компоненты не являются открытым ядром только потому, что установлены рядом с ним.
+В публичную Wiki, открытый патч, архив исходников, граф и иллюстрацию не включают закрытый код или непубличные детали. Внутренняя поставка закрытого компонента требует разрешённого доступа и выполняется по его собственным инструкциям в intrawiki. Публичный сценарий заканчивается обозначением границы и передачей вопроса ответственным Platform.
+Проверять нужно фактическое содержимое файлов, а не только названия и .gitignore. Ссылка на закрытый элемент в общем UI-каталоге также не делает его реализацию публичной. Перечень — [[sharixopen:knowledge:architecture:model_ownership|закрытые компоненты и их границы]].
+===== Какие файлы передать =====
+Патч ShariX Open содержит пути относительно корня установки и перечисляет затронутые репозитории. В публичную поставку включается только разрешённый к открытому распространению общий код, который публикуется в своём репозитории. Для закрытого общего модуля действует отдельный внутренний порядок. После публикации shared-изменения нужно оповестить ответственного Platform для проверки, тестирования и принятия по intrawiki. Инструкция ShariX Open не включает команды, пути и собственные патчи другого продукта. Независимый компонент, например Moodle-плагин, получает отдельную поставку при соответствующем задании.
+В архив вместе с патчем включают полный сценарий применения. На сценарий дают отдельную ссылку. В нём должны быть следующие сведения:
+^ Раздел сценария ^ Что указать ^
+| База и состав | Исходные commits каждого репозитория, список файлов, зависимость от предыдущих этапов и совместимость с ними. |
+| Подготовка | Нужные доступы, резервные копии, состояние репозиториев и способ переноса файлов. |
+| Проверка до изменения | Точные каталоги и команды проверки применимости патча к этой базе, включая затронутые вложенные репозитории. |
+| Применение | Команды записи, необходимые миграции, переводы, статика и синхронизация конфигурации именно для этого изменения. |
+| Публикация и передача | Какие репозитории и commits публикуются; какие сведения после публикации передать ответственному Platform, если изменён shared-модуль. |
+| Запуск и приёмка | Кто выполняет действия, какая служба затрагивается, ожидаемый результат и способ его проверки. |
+| Остановка и восстановление | При каких ошибках прекратить выполнение, что сохранить и как вернуться к согласованному состоянию. |
+Распаковка исходников поверх работающего checkout и новый самодельный установщик не заменяют штатный порядок. Оператор переносит патчи в ''/tmp'', поэтому в его командах указывают ''/tmp/ИМЯ.patch''. Автор отдельно сообщает, что файлы подготовлены локально, а перенос на сервер выполняет оператор. Изображения после серверного обновления загружает агент через согласованный API; оператору не поручают установку иллюстраций или запуск клиентского CLI для неё.
+===== Как сделать инструкцию связной =====
+В начале назвать фактический каталог и пользователя. Для ShariX Open подтверждён ''/opt/sharix-open-webapp-base''; другой путь нужно выяснить у владельца этой установки. Имена SSH-хостов, служб, веток и БД берут из действующей конфигурации. Если значение неизвестно, указать, где его получить, а не придумывать пример как готовую команду.
+Каждый следующий шаг использует результат предыдущего. Если нужно ввести параметр, объяснить его назначение и последующее использование. Все упомянутые файлы должны входить в поставку или иметь точный способ получения. Рядом с действием указывается, под кем его выполнить: deploy и root выполняют разные части процедуры.
+В конце выделить три группы:
+  * **Выполнено автором.**
+  * **Выполняет оператор.**
+  * **Не проверено.**
+Указать наблюдаемое изменение для пользователя и ожидаемые сообщения оператора. Наличие diff или успешного импорта Python не заменяет эти сведения.
+===== Порядок применения подготовленного патча =====
+  - Сохранить необходимые резервные копии и согласовать окно работы, если меняются схема или данные. Проверить затронутые репозитории и отсутствие незавершённых Git-операций.
+  - Оператор размещает файлы в ''/tmp'' и под назначенным deploy login переходит в фактический каталог установки.
+  - Выполняет проверки применимости из сценария. Для патча нескольких репозиториев одной проверки корневого Git недостаточно. При несовпадении фрагмента или появлении ''.rej'' останавливается и передаёт состояние автору поставки.
+  - Применяет изменение, проверяет результат и публикует согласованный набор репозиториев штатным ''repositories.sh''. Если в ShariX Open используются отдельные ветки развёртывания — следует порядку ''update-start → update-publish → update-finish''. Подробнее: [[sharixopen:knowledge:development:repository_flow|передача общего кода]].
+  - После публикации shared-изменения автор оповещает ответственного Platform и передаёт commits, результаты проверок и условия совместимости. Ответственный выполняет проверку, тестирование и принятие в общий код по intrawiki; эти действия не продолжают публичный сценарий ShariX Open.
+Для уже подготовленных исходников обычные фазы под deploy login выглядят так:
 <code bash>
 ./bin/install.sh deploy --strict --use-current-checkouts --permissions=check --deps=auto --no-restart &&
@@ Строка 257: / Строка 375: @@
 ./bin/check_acceptance.sh --with-runtime-audit
 </code>
+Блок выполняется из фактического корня установки. Назначение команд и параметров:
-Это последовательность фаз, а не разрешение выполнить весь блок после отказа первой команды. ''deploy'' может менять schema/config/data; ''--use-current-checkouts'' исключает обновление Git, ''--no-restart'' откладывает запуск. Успех preparation не доказывает готовность runtime state.
+  * ''deploy'' — готовит зависимости, конфигурацию, схему и данные согласно установщику.
+  * ''--use-current-checkouts'' — Git не обновляется этим запуском.
+  * ''--no-restart'' — перезапуск откладывается до следующей команды.
+  * ''&&'' — последовательность прекращается при ошибке.
-Если restart сообщает ''Restart permissions are not installed'' или ''Runtime state needs its managed isolated directory'', сверить сообщение с текущим runbook: необходимый штатный root ''activate --strict --use-current-checkouts --permissions=check'' готовит managed state/grants. Затем новый deploy login и повтор только restart. Root bootstrap, полный deploy, рекурсивный repair, ручной chmod или симлинк не назначают вместо диагностики.
+Успех подготовки ещё не означает, что приложение запущено.
-HTTP-диагностика после restart рекомендательная: отсутствие ответа/таймаут/HTTP-код остаётся видимым WARNING и не подменяет исход перезапуска службы. Permissions/service state/source/provenance errors блокируют продолжение. Имена units берутся из runtime identity, не из hostname.
+Точный сценарий указывает нужные миграции, переводы и статику и учитывает, что уже делает deploy. Новые файлы миграций не генерируют автоматически на рабочем сервере вместо подготовленной разработки.
-===== Остановка и восстановление =====
+===== Если запуск или проверка не удались =====
-При несовпадении базы, failed hunk, source conflict, незавершённой миграции или blocking guard не переходить к следующей фазе. Сначала записать, что фактически выполнено, и сравнить текущее состояние с ожидаемым. Обратное применение patch допустимо только после проверки его применимости и отсутствия новых изменений; rollback данных/миграций может требовать отдельного плана и backup. Не выполнять ''reset --hard'', удаление файлов или повтор неизвестного POST ради «чистого» результата.
+При сообщениях ''Restart permissions are not installed'' или ''Runtime state needs its managed isolated directory'' сверяют текущую процедуру: нужный штатный root ''activate --strict --use-current-checkouts --permissions=check'' подготавливает каталоги и разрешения. Затем выполняется новый deploy login и повтор только restart. Полная установка, рекурсивное исправление прав, ручной chmod или создание симлинков не подставляются вместо выяснения этой причины.
-===== Обновление знаний =====
+HTTP-диагностика после restart рекомендательная. Таймаут, сетевой отказ или HTTP-код сохраняются как WARNING и исследуются отдельно от результата перезапуска. Ошибки состояния службы, прав и проверки исходников блокируют продолжение. Имя systemd unit берут из конфигурации этой установки, а не из hostname.
-Одновременно уточняют контракт владельца, README и контекстную web-справку по роли. Wiki описывает использование и разработку продукта, Moodle — учебные объяснения. Изменённую страницу перечитывают, сохраняют её идентичность и concurrent edits, используют preview/base hash и каноническую GET-сверку. Уведомление даётся одним обзором связного этапа со ссылками; внутренние страницы не попадают в публичную группу.
+При ошибке патча, конфликте исходников или незавершённой миграции не переходят к следующей фазе. Сначала фиксируют выполненные шаги и состояние. Обратное применение патча проверяют заново; восстановление БД может потребовать резервной копии и отдельного плана. ''reset --hard'', удаление файлов и повтор записи с неизвестным результатом не являются универсальным восстановлением.
+===== Для нейросети: что проверить в собственном результате =====
+  - Проследить изменение от маршрута и формы/API до функции, модели, событий и вызывающих модулей. Найти существующую реализацию и библиотечный UI-элемент перед созданием новых.
+  - Сохранять ответственность за данные у их модуля. Для обработчиков изменять Blockly-модель, генерировать Python и проверять соответствие. В сценариях учитывать пользователя, API, таймеры и события; BPMN описывает их, а не исполняется просмотрщиком Wiki.
+  - Прочитать свою инструкцию как получатель: все ли файлы доступны, связаны ли шаги, совпадают ли пути, названы ли пользователи и условия остановки.
+  - Дать реальные ссылки на подготовленные файлы. Не заявлять серверную проверку по локальному результату или по другому продукту, не скрывать предупреждения и не включать дополнительные действия без поручения.
+===== Как обновить документацию =====
+Уточнить README нужного модуля, его описание в Wiki и контекстную справку изменённой страницы по роли пользователя. Учебные объяснения и примеры кода относятся к Moodle. Перед публикацией перечитать текущую страницу, сохранить правки других авторов, выполнить preview и сравнить сохранённый текст повторным чтением.
+Обновления Wiki обычно сопровождаются одним обзором этапа со ссылками. Если владелец просит выполнить редактуру без уведомлений, это указание применяется к этому проходу. Общие правила подтверждения результата — [[sharixopen:knowledge:development:verification|приёмка изменений]].
 ===== Проверенная исходная база: 29.10.2026 =====
@@ Строка 279: / Строка 413: @@
   * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/ticket_blockly_codegen.py|sharix-open-handlers-backend: ticket_blockly_codegen.py]] — 50baf376e224.
   * [[https://git.sharix-app.org/ShariX_Open/sharix-open-handlers-backend/src/commit/50baf376e224d915a87d63240f3f339b3dda9afa/tools/check_canonical_ticket_codegen.py|sharix-open-handlers-backend: tools/check_canonical_ticket_codegen.py]] — 50baf376e224.
+===== Уточнение команд: 30.10.2026 =====
+В [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/c19e6651449483d898f5ae33548f97c0ef7e1cd2/bin/repositories.sh|bin/repositories.sh]] функция require_open_update_mode разрешает update-* только ShariX Open. Эти команды относятся к процедуре ShariX Open.
+===== Уточнения владельца сразу фиксируются в документации =====
+По поручению владельца от 01.11.2026 новое согласованное требование, меняющее продуктовый контракт, права, границы модулей, workflow или применимость проверок, сразу заносится в соответствующую предметную Wiki в рамках того же задания. Правило не должно оставаться только в переписке до следующего прохода.
+В том же изменении устранить противоречия затронутых AGENTS.md, CODING_POLICY и README. Более позднее явное уточнение владельца имеет приоритет перед устаревшим локальным текстом. Учебные объяснения остаются в Moodle; предметные правила использования и разработки — в Wiki.
+Отдельно обозначать согласованный контракт, подготовленное изменение исходников и проверенный результат установки. Перед записью перечитать текущую страницу и сохранить чужие изменения; после preview/publish выполнить GET/hash-сверку и предусмотренное уведомление со списком страниц и ссылками. Запись правила в Wiki не является разрешением на deploy и не подтверждает серверную приёмку.
 ~~SHARIX_KNOWLEDGE_RELATED~~