Различия

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

--- sharixopen:knowledge:development:human_ai_handoff [2026/10/31 09:14] – [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": "Как подготовить изменение и инструкцию для оператора",
     "status": "review",
@@ Строка 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": [
@@ Строка 219: / Строка 233: @@
             "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": "0d514ca7b17060727dbe9844c2d820b7983efcd17e8c2fc3a845c12a3b52e3bb",
+    "content_sha256": "62ca90aaf5770d9b02fdf475582b0170744d91fda469864fee1996c74badabee",
     "schema": 1
 }
@@ Строка 228: / Строка 293: @@
 ~~NOCACHE~~
-Человек, получающий исправление, должен понимать, какой файл взять, к какой версии он подходит, где выполнить команды и как определить результат. Подготовка патча заканчивается цельной поставкой: сам патч, полный сценарий применения и сведения о выполненных проверках.
+**Назначение:** [[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|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#peredacha_izmenenij|Разработка → Передача изменений]] · [[sharixopen:knowledge:classification:topics#proverka|Разработка → Проверка]].
+Человек, получающий исправление, должен понимать, какой файл взять, к какой версии он подходит, где выполнить команды и как определить результат. Подготовка патча заканчивается цельной поставкой:
+  * сам патч;
+  * полный сценарий применения;
+  * сведения о выполненных проверках.
 Эта страница задаёт порядок передачи. Конкретная поставка должна содержать команды для своей базы и фактических каталогов. Установка приложения описана в [[sharixopen:knowledge:operations:deploy|отдельной процедуре]].
@@ Строка 240: / Строка 317: @@
 Старую карточку и расшифровку сверяют с текущим кодом. Если нужного checkout нет, проверка похожего продукта не заменяет его. Сначала читают актуальные README, CODING_POLICY, AGENTS и инструкции Wiki относящихся к работе репозиториев.
+===== Что можно включать в публичную поставку =====
+Проверить LICENSE каждого репозитория и отметить отдельно:
+  * открыт ли код;
+  * является ли модуль общим;
+  * где он используется.
+Эти признаки не заменяют друг друга. Конструктор сервиса и другие отдельно лицензируемые закрытые компоненты не являются открытым ядром только потому, что установлены рядом с ним.
+В публичную Wiki, открытый патч, архив исходников, граф и иллюстрацию не включают закрытый код или непубличные детали. Внутренняя поставка закрытого компонента требует разрешённого доступа и выполняется по его собственным инструкциям в intrawiki. Публичный сценарий заканчивается обозначением границы и передачей вопроса ответственным Platform.
+Проверять нужно фактическое содержимое файлов, а не только названия и .gitignore. Ссылка на закрытый элемент в общем UI-каталоге также не делает его реализацию публичной. Перечень — [[sharixopen:knowledge:architecture:model_ownership|закрытые компоненты и их границы]].
 ===== Какие файлы передать =====
-Патч ShariX Open содержит пути относительно корня установки и перечисляет затронутые репозитории. Общий код включается в эту поставку и публикуется в своём Git-репозитории. После публикации shared-изменения нужно оповестить ответственного Platform для проверки, тестирования и принятия по intrawiki. Инструкция ShariX Open не включает команды, пути и собственные патчи другого продукта. Независимый компонент, например Moodle-плагин, получает отдельную поставку при соответствующем задании.
+Патч ShariX Open содержит пути относительно корня установки и перечисляет затронутые репозитории. В публичную поставку включается только разрешённый к открытому распространению общий код, который публикуется в своём репозитории. Для закрытого общего модуля действует отдельный внутренний порядок. После публикации shared-изменения нужно оповестить ответственного Platform для проверки, тестирования и принятия по intrawiki. Инструкция ShariX Open не включает команды, пути и собственные патчи другого продукта. Независимый компонент, например Moodle-плагин, получает отдельную поставку при соответствующем задании.
 В архив вместе с патчем включают полный сценарий применения. На сценарий дают отдельную ссылку. В нём должны быть следующие сведения:
@@ Строка 262: / Строка 353: @@
 Каждый следующий шаг использует результат предыдущего. Если нужно ввести параметр, объяснить его назначение и последующее использование. Все упомянутые файлы должны входить в поставку или иметь точный способ получения. Рядом с действием указывается, под кем его выполнить: deploy и root выполняют разные части процедуры.
-В конце разделить **«Выполнено автором»**, **«Выполняет оператор»** и **«Не проверено»**. Указать наблюдаемое изменение для пользователя и ожидаемые сообщения оператора. Наличие diff или успешного импорта Python не заменяет эти сведения.
+В конце выделить три группы:
+  * **Выполнено автором.**
+  * **Выполняет оператор.**
+  * **Не проверено.**
+Указать наблюдаемое изменение для пользователя и ожидаемые сообщения оператора. Наличие diff или успешного импорта Python не заменяет эти сведения.
 ===== Порядок применения подготовленного патча =====
@@ Строка 278: / Строка 375: @@
 ./bin/check_acceptance.sh --with-runtime-audit
 </code>
-Блок выполняется из фактического корня установки. ''deploy'' готовит зависимости, конфигурацию, схему и данные согласно установщику. ''--use-current-checkouts'' означает, что Git не обновляется этим запуском; ''--no-restart'' откладывает перезапуск до следующей команды. Связка ''&&'' прекращает последовательность при ошибке. Успех подготовки ещё не означает, что приложение запущено.
+Блок выполняется из фактического корня установки. Назначение команд и параметров:
+  * ''deploy'' — готовит зависимости, конфигурацию, схему и данные согласно установщику.
+  * ''--use-current-checkouts'' — Git не обновляется этим запуском.
+  * ''--no-restart'' — перезапуск откладывается до следующей команды.
+  * ''&&'' — последовательность прекращается при ошибке.
+Успех подготовки ещё не означает, что приложение запущено.
 Точный сценарий указывает нужные миграции, переводы и статику и учитывает, что уже делает deploy. Новые файлы миграций не генерируют автоматически на рабочем сервере вместо подготовленной разработки.
@@ Строка 312: / Строка 416: @@
 ===== Уточнение команд: 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~~