Тип: procedure · Статус: сведения требуют сверки с действующей установкой; архитектурные правила сформулированы как целевой контракт.

Раздел: Разработка Open: обязательные правила

Обнаружить фактические локальные ветки и SHA → проверить чистоту → работать с каноническим upstream master для shared → провести тесты → publish → вернуться к настроенной deployment branch.

Не переносить git-каталоги в публикационные ZIP, не патчить один и тот же shared checkout независимо на двух сборках, не подменять upstream произвольным локальным ZIP.

Обновление источников не должно удалять реальный .env, ключи, лицензии, миграционные факты и service identity.

• Порядок изменения shared: Open → Platform
• Лицензии, исходники и provenance сборки

Разрабатывать/применять patch и запускать deploy удобно в su - sharix_open_deploy (example, actual login из install.cfg). У пользователя есть home/Bash и Git config; home не обязан совпадать с /opt установки. Настройка identity предлагает defaults только при недостающих полях, не копирует root credentials и не даёт доступа к remote. Локальные user.name/user.email отдельного module repo имеют приоритет над global; bootstrap не переписывает осознанные overrides. Для push от своего лица использовать свою Unix/Git identity с выданными operator group permissions, не safe.directory=*.

Перед новым изменением прочитать actual repository status и diff, не включать чужие файлы. Если все выбранные owners configured на master, работать прямо на нём. Если configured non-master: адресный update-start → patch/tests → update-publish → update-finish с возвратом в deployment branch; не переключать Landing/другие owners без задачи. После публикации другое дерево получает commit через Git, не второй patch.

Пример для изменения installer, conf и двух shared owners, ТОЛЬКО когда изменены именно они и весь diff согласован:

./bin/repositories.sh status --repo . --repo conf \
  --repo sharix_sysadmin --repo handlers_backend
./bin/repositories.sh push --repo . --repo conf \
  --repo sharix_sysadmin --repo handlers_backend \
  -m "Update Open installation lifecycle"

Здесь нет –local: он исключает shared даже при явном –repo. Не разделять mixed change на частичный local push после failed shared preflight. Identity всех changed checkout проверяется до первого commit/push; read-only status ничего не настраивает. Пароли remote не помещать в env, config examples, command arguments или документацию.

deploy –use-current-checkouts не обновляет Git намеренно. Без этого флага ordinary deploy использует штатный strict Git update; prepared вариант нужен, когда exact source уже получен/проверен отдельно. В обоих случаях schema/static/ dependency/config steps сохраняются. –deps=auto — не обещание «ничего тяжёлого». Проверка compliance/source provenance не отключается ради неопубликованного патча.

Сверено 2026-10-27 по опубликованному Open root ec9bf2a и Open config 84597d4. Проверены исполняемые пути install.sh, install_roles.sh, install_permissions.py, deploy_control.sh, install_nginx.sh и env/state helpers; не только сообщения Git. Владелец подтвердил успешный запуск Open после исправлений. Установка nginx с новым вопросом и повторная независимая проверка Testopen ещё требуют отдельной host-приёмки. Это не объявление релиза и не подтверждение production. Редакционный status=review относится к статье, не к наличию реализации.