Назначение: Проверка и критерии приёмки. Продукт: 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.