ShariX Open Docs

Инструменты пользователя

Инструменты сайта

Вы посетили: • constructor • practice • nextcloud • tz_map • handler_discovery • implementation • testkit • user_model • capability_resolution • development
sharixopen:knowledge:development:start

Содержание

Разработка ShariX Open

Назначение: Указатель раздела. Продукт: ShariX Open.

Для кого: Разработчик · Рецензент и приёмщик · Нейросеть.

Темы: Разработка → Методы · Разработка → Передача изменений.

Навигация: База знаний → Разработка.

Этот раздел помогает выбрать репозиторий и пройти от задачи до опубликованного изменения. Полный маршрут работы находится в методологии, подробные правила — в порядке разработки.

Что выяснить до изменения

  • Поведение: какое действие пользователя нужно исправить или добавить.
  • Владелец: какой модуль определяет данные и разрешённые операции.
  • База: ветка, commit и уже применённые связанные изменения.
  • Лицензия: можно ли включать этот компонент в публичный патч и документацию.
  • Потребители: какие формы, API, handlers и приложения используют изменяемый контракт.
  • Проверка: какой сохранённый и видимый результат подтвердит выполнение задачи.

Например, общий заказ Orders принадлежит dbsynce, Ticket — tickets, а локальное исполнение и Stage — webservice_running. Похожее поле в соседнем модуле не является основанием создать второго владельца. Выбор описан во владении моделями.

Выбрать рабочую инструкцию

Что меняется Начальная точка Что должно остаться согласованным
Общие данные Модель, её serializer/view, предметная операция и миграции. Существующие данные, API и вызовы других модулей.
API Маршрут, входной допуск, actor, объект и функция действия. Права на объект, допустимое состояние, ошибки и внешние последствия.
Интерфейс Библиотечный компонент и его использование на настоящей странице. Серверная проверка, подписи, ошибки, клавиатура, узкий экран и доступные темы.
Handler Blockly workspace и генераторы. Python, provenance, API/capabilities, события, таймеры и BPMN.
Установка Фазовый install/deploy/restart. Фактическая identity, пользователи, конфигурация и предусмотренные службы.

Для нового API сначала прочитать контракт операции. Для изменения заказа полезен сквозной сценарий создания через API: он показывает, почему запись заказа, назначение исполнителя и уведомление — разные результаты.

Порядок работы

  1. Найти текущую реализацию и репозиторий владельца. Прочитать README, CODING_POLICY и AGENTS относящейся версии.
  2. Проверить места вызова и определить требуемое поведение, сохраняя существующие контракты там, где задача их не меняет.
  3. Подготовить изменение в правильном репозитории. Миграции и generated-файлы включить в тот же согласованный этап, когда они действительно нужны.
  4. Выполнить проверки по матрице приёмки. Отдельно отметить source-проверку, локальный тест и проверку установленного приложения.
  5. Опубликовать исходники по порядку Git-репозиториев. Публикация кода и запуск установки — разные действия.
  6. Передать человеку файлы и полный сценарий применения, указав базу, роли, каталоги, проверки, остановку при ошибке и восстановление.
  7. Обновить документацию и справку затронутой страницы. Если меняется общий модуль, выполнить предусмотренное оповещение ответственного другого продукта.

Общие модули и граница Platform

Shared означает использование несколькими продуктами, а не открытую лицензию. Для каждого репозитория сверяют LICENSE и COMPLIANCE. Закрытые исходники и внутренние процедуры не включают в публичную поставку ShariX Open.

После публикации изменения открытого shared-модуля ответственному Platform передают:

  • репозитории, ветки и commits;
  • смысл изменения и зависимые версии;
  • требования к совместимости, миграциям и конфигурации;
  • выполненные проверки ShariX Open и оставшиеся ограничения.

Ответственный проверяет, тестирует и принимает изменение по intrawiki. Не требуется получать закрытый checkout или автоматически применять тот же патч во второй установке. Порядок — передача shared-изменения.

Материалы раздела

Как устроена навигация раздела

Список ниже и граф строятся по метаданным страниц. Подраздел «Методология» имеет собственный родительский раздел «Разработка»; содержательные связи с API, моделями и эксплуатацией задаются отдельно. Постоянные URL сохраняются при уточнении текста. При обновлении проверяют и обычные ссылки, и taxonomy.parents/relations — одной видимой ссылки недостаточно для машинной иерархии.

Граф знаний ShariX

Фильтруйте по разделам и выбирайте узлы, чтобы перейти к документам.

Текстовая навигация по документам

Каталог знаний

Исходники, сверенные 31.10.2026

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение состояния сервера или выполнения процесса в установленной системе.

Ориентиры дальнейшей разработки

Это требования и предметные решения для будущих изменений, а не перечень уже готовых функций.

Связанные материалы

sharixopen/knowledge/development/start.txt · Последнее изменение: — sx_knowledge_api_open
© 2022 ShariX