Ниже — короткий, но “боевой” регламент, который можно принять как стандарт для всех решений на SIMAI Framework 4. Он поможет сделать установку предсказуемой, а деинсталляцию — безопасной и понятной (в том числе для интеграторов).

1) Паспорт решения и совместимостьlink

Зафиксировать в мастере (и в описании решения):

код решения/мастера (code) и версию (хотя бы в виде VERSION/stage_renew);
зависимости: какие модули должны быть установлены до запуска (минимум simai.framework, обычно simai.property);
поддерживаемые языки/сайты (например ru, en) и ожидаемые идентификаторы сайтов;
требования к окружению (минимально: версия PHP как “ориентир по Bitrix”, но лучше проектно фиксировать отдельной строкой в решении).

Практический эффект: мастер не стартует “в неизвестном окружении” и не ставит решение частично.

2) Точка входа и параметры исполнения (AJAX-режим)link

В установщике решения (install/index.php) зафиксировать стандарт:

запуск мастера через simai:sf.wizard;
включённый AJAX_MODE = Y и согласованные значения AJAX_TIME_STEP / AJAX_TIME_INTERVAL;
отключение кэша компонента мастера (CACHE_TYPE = N) на время установки.

Практический эффект: длинные операции (распаковка/импорт) выполняются устойчиво и без таймаутов.

3) Схема ввода данных: какие параметры запрашиваем и куда применяемlink

Для .property.config.php принять стандарт:

перечень параметров мастера: только то, что действительно нужно (домен/организация/почта/цвета/режим установки);
типы полей (string, color, list, checkbox) и дефолты;
явная договорённость: куда мастер пишет эти значения:
- в настройки сайта ({site_dir}/simai.data/.site.property.php),
- и/или в .property.php разделов,
- и/или в опции (если используется такой сценарий).

Практический эффект: у вас появляется единое правило, где живут “настроечные” данные решения.

4) Карта создаваемых сущностей (инвентаризация артефактов)link

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

файлы/папки (куда копируем: дерево сайта, {site_dir}/simai.data, include-области и т.д.);
инфоблоки: какие архивы импортируем, какие коды инфоблоков/типов ожидаем;
HL-блоки (если создаются), какие таблицы/поля ожидаются;
опции и настройки (если применяется импорт опций);
urlrewrite и прочие “системные настройки” Bitrix;
дополнительные сущности (почтовые события/шаблоны, агенты/кроны — если они входят в решение).

Практический эффект: решение становится проверяемым — можно пройтись чек-листом и понять, что именно поставилось.

5) Идентификаторы “в кодах”, а не в IDlink

Зафиксировать обязательное правило:

всё, что возможно, мастер создаёт/настраивает через коды (типы инфоблоков, коды инфоблоков, символьные коды сущностей/настроек), а не через ID;
если где-то вынужденно появляются ID — мастер должен сохранять их в предсказуемое место (например, в опции решения или в структуру данных шага), чтобы другие шаги не “угадывали”.

Практический эффект: переустановка/перенос на другой сервер не ломает связи.

6) Политика “повторного запуска” и восстановленияlink

В .wizard.config.php лучше заранее определить поведение при повторном запуске мастера:

режим “установить заново” (с очисткой/пересозданием сущностей),
режим “обновить” (применить миграции без удаления),
режим “проверить” (диагностика без изменений) — если вы такое используете.

И главное: как мастер определяет, что решение уже установлено (маркер установки).

Практический эффект: исчезают ситуации “запустили ещё раз и получили дубли”.

7) Деинсталляция: что удаляется и по каким правиламlink

Вам нужно формализовать минимум два режима удаления (даже если UI пока не готов):

Полное удаление решения Удаляются:
- файлы, которые мастер копировал в проект;
- инфоблоки/типы/сущности, которые мастер создавал;
- HL-блоки и таблицы, если они создавались решением;
- настройки/опции, заведённые решением.
Удаление только файлов решения (без данных) — если вы хотите такой режим Удаляются:
- только файлы/пакеты,
- а данные (инфоблоки/контент) сохраняются.

И обязательно правило безопасности: если мастер устанавливался “поверх” живого проекта, он не должен удалять то, что не создавал (нужны маркеры/реестр созданного).

Практический эффект: деинсталляция перестаёт быть “страшной” и становится управляемой.

8) Протоколирование и диагностикаlink

Договориться, что мастер пишет “след установки”:

что делал (шаги),
какие сущности создал (коды/ID),
где положил файлы,
какие ошибки возникли.

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

Практический эффект: поддержка и внедрение становятся быстрее.

9) Финальная проверка после установки (минимальный smoke-test)link

После выполнения цепочки шагов мастер должен гарантировать минимум:

сайт открывается без PHP ошибок;
активный шаблон включён и SF4 подхватывается;
базовые grid_view_* выставлены и соответствующие папки view существуют;
хотя бы одна тестовая страница/область собирается гридом;
кэш сброшен/инвалидирован в рамках того, что менялось.

Практический эффект: установка не считается “успешной”, пока решение реально не работает.