Назначение: Подход к разработке. Продукт: ShariX Open · Общий компонент.

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

Темы: Разработка → Методы · Разработка → Проверка.

Работа начинается с наблюдаемой задачи и заканчивается понятным, проверяемым результатом. Здесь описан порядок разработки ShariX Open. Он не требует доступа к закрытому коду или серверам другого продукта.

Для каждого затронутого репозитория прочитать LICENSE и, если есть, COMPLIANCE. Отдельно определить назначение модуля, возможность его совместного использования и режим доступа к исходникам. Название ShariX Open, установка в его каталоге и метка shared не заменяют эту проверку.

Слово shared означает совместное использование модуля, а не открытую лицензию. В установке ShariX Open могут присутствовать отдельно лицензируемые закрытые компоненты. Их внутренние модели, алгоритмы и инструкции описываются в intrawiki. Публичная Wiki обозначает только название и границу; за деталями и согласованием доступа обращаются к ответственным со стороны Platform.

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

1. Прочитать карточку и комментарии, определить действие пользователя и ожидаемый результат.
2. Найти маршрут, view/форму/serializer, вызываемую функцию, модель и связанные события. Проверить, не реализована ли функция иначе.
3. Определить репозиторий изменения и исходный commit. Прочитать его README, CODING_POLICY и AGENTS в пределах разрешённого доступа. Для закрытого репозитория эта публичная процедура не является разрешением на его чтение или публикацию.
4. Найти существующие API, модели, реестры и элементы UI. Расширить нужную реализацию, а не копировать её в соседний модуль.

Источники и уровень подтверждения различают по правилам работы со сведениями. При отсутствии нужного checkout проверка похожего продукта не заменяет чтение нужного кода.

Изменение общей модели и её бизнес-состояния выполняется у владельца. Например:

• Orders — в dbsynce;
• Ticket — в tickets;
• этапы и материалы исполнения — в webservice_running.

Локальный serializer не должен становиться обходом разрешённой операции общего заказа. Подробно — владение моделями и API.

Для UI нужны библиотечный элемент, понятные ru/en тексты и помощь по роли. Существующую геометрию страницы не меняют без задачи на переработку дизайна. Публичные форматы, идентификаторы и названия вроде MENU_ALG не переименовывают как косметическую правку без анализа вызывающего кода.

Редактируемый источник алгоритма — типизированная Blockly-модель: используются поддерживаемые блоки с явным назначением и параметрами. Из неё генерируется Python, затем проверяются совпадение с поставляемым файлом и сведения о происхождении: исходная модель, генератор, версия и контрольные суммы. Рабочий процесс импортирует выбранный Python-файл; JSON Blockly во время обработки заявки не интерпретируется.

Если Python уже выполняет действие, которого нет в Blockly:

1. Восстановить действие и его условия в модели.
2. При необходимости добавить узкий переиспользуемый блок.
3. Перегенерировать Python.
4. Выполнить поведенческие проверки.

Перегенерация неполной модели с потерей работающей функции и ручная замена одних хешей не устраняют расхождение.

В модели должны быть видны:

• условия;
• переходы;
• уведомления;
• передача другому обработчику;
• ожидания;
• повторы;
• завершение.

Библиотечная операция имеет описанный успех и отказ; под её именем не скрывают целый новый процесс или произвольный Python.

В одном этапе изменения учитывают:

• Blockly-модель;
• блоки и генераторы;
• шаблоны генерации;
• Python;
• сведения о происхождении;
• набор блоков редактора;
• помощь и переводы;
• проверки.

Неизвестный блок или изменившийся генератор требуют явной ошибки, а не угадывания старого поведения. Самостоятельный импорт обработчика не должен тянуть Django/ORM; интеграция подключается в предусмотренном месте.

Для процесса сначала рассматривают BPMN. На схеме показывают алгоритм и внешних участников:

• кто получает запрос;
• где действует человек;
• какой API вызывается;
• какое событие возвращается;
• что происходит при отказе, повторе и истечении срока.

Проверяют Blockly, Python и существенные операции/API, а не только картинку.

BPMN на Wiki описывает процесс и не запускает его. Имена настроек таймеров берут из кода, значения конкретного сервера не угадывают. При изменении источников сверяют связанную схему и текст с новой версией. Встроенный Git-вариант, локальная версия и фактически выбранный файл могут различаться; это нужно установить при проверке.

Проверки выбирают по поведению:

• API: права и данные.
• Модель: сохранённая схема и миграции.
• UI: настоящая форма и ошибки.
• Обработчик: генерация и внешние события.

Локальные проверки с имитацией зависимостей отделяют от проверок установленного ShariX Open. Подробно — критерии приёмки.

Для установки отдельно проверяют:

• пользователя, под которым работает приложение;
• файловые права;
• статику при DEBUG=False;
• готовность обработчиков.

Успех manage.py check от root не заменяет проверку от runtime-пользователя. Разрешение читать или менять env-файл в вебе не является новой Django-ролью. Команды подготовки, запуска и проверки находятся в инструкции установки.

Подготовить патч на известной базе и полный сценарий применения; указать выполненные проверки и оставшиеся вопросы. Следующий человек должен понимать, где лежат файлы, под кем и из какого каталога выполнить действия и какой результат ожидается. Порядок — передача результата оператору.

Общие (shared) модули ShariX Open могут использоваться и в Platform. После публикации изменения нужно оповестить ответственного со стороны Platform и передать:

• репозитории и commits;
• описание изменения;
• результаты проверки.

Ответственный проверяет изменение, тестирует его и оформляет принятие в общий код по своим инструкциям в intrawiki. Действия на Platform не выполняются как продолжение публичной инструкции ShariX Open.

Состав уведомления и граница ответственности — публикация общего модуля.

Старые карточки и расшифровки помогают понять замысел, но имена методов, модели, ветки и команды заново сверяют с кодом. При расхождении сначала выясняют требуемое поведение; код не меняют только ради буквального совпадения со старым абзацем. Планы и отложенные работы обозначают отдельно от реализованного.

Обновляют существующие постоянные страницы с сохранением истории и чужих правок. Wiki описывает использование и разработку ShariX Open; учебные объяснения, примеры кода, практика и дипломы относятся к Moodle. Публичная инструкция не зависит от закрытого endpoint, credentials или обязательного чтения intrawiki.

Смежные правила: лицензии и исходники, релизы, терминология, справка страниц, веб и мобильный интерфейс.

Первоначальная source-проверка 2026-10-26: Open root d95cff6 (историческая база): install.sh, bin/utils/install_modes.sh, bin/repositories.sh, runtime_update.sh. Это source-проверка, не подтверждение состояния каждого сервера и не релизная приёмка.

Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.

• sharix-open-webapp-base: CODING_POLICY.md — f65376cdb5a3.
• sharix-open-webapp-base: bin/repositories.sh — f65376cdb5a3.

• sharix-open-webapp-base: CODING_POLICY.md.
• sharix-open-webapp-base: bin/repositories.sh.