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

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

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

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

Перед запуском записать:

• изменённые репозитории и commits;
• затронутый пользовательский сценарий;
• ожидаемый результат;
• место проверки: локальный checkout, изолированная тестовая среда или действующая установка ShariX Open;
• состав модулей, настройки и исходную ветку, от которых зависит результат.

Для каждого компонента проверить LICENSE и COMPLIANCE, если он есть. Shared означает совместное использование, а не открытую лицензию. Эта публичная инструкция не требует доступа к закрытому коду: его внутреннюю часть проверяет ответственный по intrawiki.

Из фактического корня подготовленной установки под её назначенным deploy login:

git diff --check
./venv/bin/python manage.py check

У каждого изменённого вложенного Git-репозитория отдельно проверяют diff. Django check требует подходящего окружения и конфигурации; отсутствие зависимости на локальном компьютере фиксируется как ограничение проверки, а не как доказательство исправности сервера.

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

Для простого изменения текста выбирают относящиеся к нему проверки. Для изменения прав, конфигурационного владельца, источников или lifecycle требуется сценарий через каноническую операцию с проверкой и сохранённого, и видимого состояния.

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

./venv/bin/python manage.py makemigrations --check --dry-run

Найденный drift исправляют миграцией в репозитории владельца, затем публикуют её с кодом. Не запускать обычный makemigrations на рабочем сервере ради получения зелёной проверки и не использовать –fake для обхода неизвестного состояния.

Если установка использует историческую цепочку и canonical baseline, действует штатная migration convergence: проверка опубликованных исходников/manifest, допустимого архива уже применённых локальных миграций, drift и проверка схемы перед записью истории. Не изобретать новый baseline по текущим моделям. Операции записи выполняются только по сценарию развёртывания и с подготовленным восстановлением.

Для подготовленного окружения ShariX Open из его фактического корня:

./bin/check_acceptance.sh

Текущий default-путь:

• не создаёт Django test database;
• не выполняет live HTTP-вызовы RussianPost/Platform;
• запускает набор source/configuration guards и предусмотренные проверки.

Это не означает, что можно без разбора запускать любой manage.py test на рабочей базе.

После предусмотренного сценарием запуска/перезапуска работающей установки:

./bin/check_acceptance.sh --with-runtime-audit

Опция добавляет штатный audit_installation.sh для настроенной установки. Source-only проверка на компьютере разработчика не заменяет этот результат. Команда приёмки сама по себе не устанавливает зависимости, не применяет патч и не заменяет deploy/restart.

Опция –cleanup-artifacts явно удаляет найденные файлы применения/резервные артефакты. Не добавлять её в обычную приёмку для сокрытия .rej: сначала разобраться с неприменённой частью и сохранить нужные свидетельства. Без этой опции default-путь оставляет такие артефакты для проверки.

Порядок установки и перезапуска — развёртывание. Соответствующий этап блокируют:

• ошибки permissions;
• ошибки состояния служб;
• ошибки обязательных source/provenance guards.

Рекомендательное HTTP-предупреждение после restart записывают отдельно: оно не доказывает отказ перезапуска служб и не позволяет объявить сайт доступным без ответа.

В отчёте указать:

1. версию кода и среду;
2. конкретное проверенное действие и ожидаемый результат;
3. команды и их фактический итог;
4. сохранённое состояние и видимый результат;
5. что осталось непроверенным, почему и кто должен проверить.

Например: «Проверены модели и API на commit …; найдено расхождение order/order_synced. Runtime-запрос не выполнялся. Исправность локального endpoint не подтверждена». Такой отчёт полезнее отметки «всё проверено» после импорта.

Общий модуль может использоваться Platform. После публикации нужно оповестить её ответственного и передать commits, условия совместимости и результаты. Он проверяет и принимает изменение по intrawiki; результат ShariX Open нельзя записывать как успешную проверку Platform. Порядок — передача shared-изменений.

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

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

• sharix-open-webapp-base: CODING_POLICY.md.
• sharix-open-webapp-base: bin/check_acceptance.sh.
• sharix-open-webapp-base: bin/install.sh.
• sharix-open-webapp-base: bin/utils/migration_convergence.sh.

Отключённый опциональный модуль находится вне приёмки целиком. Не проверять, не компилировать и не исправлять его исходники, шаблоны, переводы, зависимости или runtime ради прохождения приёмки. Не устанавливать и не включать его для получения зелёного результата. Наличие checkout не делает модуль активным.

Активный состав определяется штатным resolver по конфигурации установки. Отключённая или неподключённая опциональная часть получает NOT APPLICABLE. Обязательное ядро, активные модули и ошибки определения состава остаются блокирующими; смешанный guard сохраняет обязательную часть, исключая отключённую опциональную.

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