Шаги мастера конфигурируются с указанием списка actions, параметров шага и шаблона отображения (sf.wizard.stage)link

В SF4 мастер задаётся конфигурацией, где перечислены шаги (stage) и для каждого шага указан код действия (action) и параметры его выполнения. На практике “шаг” в конфиге — это один элемент массива действий: он получает человекочитаемое имя, code действия и, при необходимости, ключи для обмена данными (data_input_code, data_output_code) и parameter.

Отображение шага на экране выполняет компонент шага (sf.wizard.stage): он берёт описание текущего шага из конфигурации мастера, запускает действие по code, показывает форму/прогресс и фиксирует результат шага, чтобы мастер мог продолжить работу со следующего этапа.

Паттерн шага: структура данных шага (название, actions, параметры формы/вывода, переходы между шагами)link

Минимальная структура шага в конфиге мастера выглядит так:

name — подпись шага в интерфейсе (может быть пустой, если шаг служебный).
code — код action, который будет выполнен.
data_input_code — откуда брать входные данные (ключ в общем хранилище мастера).
data_output_code — куда писать результат (ключ в общем хранилище мастера).
parameter — параметры конкретного действия.
autocomplete — автопереход после выполнения (если шаг не требует ручного подтверждения/ввода).

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

Группировка actions: сценарии установки, импорта/экспорта, настройки сайта, работы с файлами/iblock — связывать через конфигурацию шаговlink

Группы действий удобнее всего понимать не как “список функций”, а как связки шагов, которые решают одну задачу. На типовом потоке установки/импорта (как в вашем конфиге) обычно выделяются такие связки:

Выбор контекста установки: шаг, который формирует site_config (например, выбор сайта/директории).
Файлы и структура: file.copy (копирование шаблонов/корня/файлов сайта), затем replace.code (подстановка плейсхолдеров).
Маршрутизация: urlrewrite.add (применить правила).
Настройки окружения: data.import.file → option.import.data (загрузить конфиг и применить опции).
Права/группы: data.import.file → usergroup.import.data.
Контент: импорт типов инфоблоков и импорт архивов инфоблоков.
Завершение: redirect (переход в нужный раздел/мастер).

Такое группирование полезно в документации: по нему видно, какие шаги “критичные” (меняют файловую систему/БД), а какие вспомогательные (загрузка конфигов в память мастера).

Где смотреть примеры/структуруlink

Практическая точка входа для разработчика — каталог мастера:

/simai/wizard/master/<код_мастера>/

Там лежит конфигурация мастера (обычно .wizard.config.php) и “пакет” данных мастера (папка data/ рядом с конфигом). Сами действия, которые вызываются по code, лежат в:

/simai/wizard/action/<code>/

Если нужно расширить мастер без правки системных действий, чаще всего делают это через добавление/изменение данных внутри конкретного мастера (его data/), а не через редактирование каталога /simai/wizard/action/.

Термины: wizard (контейнер), stage (шаг), action (действие), package (архив/набор данных для импорта/установки)link

Wizard — “контейнер” мастера: запускает сценарий, хранит состояние и данные между шагами.
Stage — шаг мастера: один этап интерфейса и выполнения.
Action — действие шага: исполняемая логика, которая делает работу (копирует файлы, применяет опции, импортирует инфоблоки).
Package — набор данных мастера: файлы и архивы, которые мастер читает/распаковывает/импортирует (например, конфиги и zip-архивы инфоблоков).

Минимальный пример шага: actions, параметры формы, шаблон вывода; привязка действий и переходовlink

Ниже — минимальный пример “практического паттерна” из вашего сценария: сначала загрузить данные из файла в хранилище мастера, затем применить их отдельным действием.

array(
    "name" => "Загрузить опции",
    "code" => "data.import.file",
    "data_output_code" => "option",
    "autocomplete" => "Y",
    "parameter" => array(
        "file" => Wizard::getLocal(__DIR__) . "/data/config/.option.config.php",
    ),
),
array(
    "name" => "Применить опции",
    "code" => "option.import.data",
    "data_input_code" => "option",
    "autocomplete" => "Y",
    "parameter" => array(),
),

Здесь видно главное:

первый шаг кладёт результат в общий контейнер данных (option);
второй шаг читает option и применяет его;
переход между ними обеспечивается порядком шагов и autocomplete.

Устаревшие actions: deprecated и рекомендуемые альтернативыlink

В поставках SF4 могут встречаться действия, которые исторически помечаются как “устаревшие” и оставлены для совместимости (например, связанные с перекодировкой, переводом, выбором языка/директорий). Для документации это важнее всего в одном аспекте: не строить новые сценарии на таких действиях, если задачу можно решить “рабочими” связками.

Практическая альтернатива обычно выглядит так:

вместо “специальных” действий под редкие сценарии — связка file.copy + replace.code + импорт конфигов/данных;
вместо сложной логики выбора — один подготовительный шаг (формирование site_config) и далее линейный сценарий.

Если в вашем проекте принято не фиксировать deprecated-статус, этот подраздел можно оставить как короткое предупреждение: “есть исторические действия, новые сценарии строим на базовых группах”.

Хранение конфигурации: файлы настроек шагов/мастера и состав полей; ветвление сценариевlink

В вашем текущем примере конфигурация мастера и пакет данных лежат рядом с мастером (через Wizard::getLocal(__DIR__) мастер читает файлы из data/… внутри своей директории). Это даёт понятную переносимость: “мастер = конфиг + пакет”.

Размещение конфигурации мастера в {site_dir}/simai.data не подтверждено по приложенному сценарию: simai.data у вас используется как слой данных сайта (шаблон/конфиги сайта), а пакет мастера живёт в директории мастера. Если вы всё же хотите вынести часть “переменных” мастера в simai.data, это лучше оформлять как проектное соглашение и явно описывать, какие поля там лежат и кто их читает (чтобы не смешивать “пакет установки” и “данные сайта”).

По составу полей, которые реально используются в шагах (по вашему конфигу):

name, code, autocomplete
data_input_code, data_output_code
parameter (как массив параметров; структура зависит от action)

Работа с пакетами: ожидаемые директории/имена архивов, правила размещения и чтения пакетных данныхlink

Пакет мастера в вашем сценарии читается из подпапок data/ внутри директории мастера. Как минимум используются такие типы “пакетных” данных:

data/bitrix/templates/ — источник для file.copy в /bitrix/templates/
data/root/ — источник для file.copy в корень сайта (/)
data/site/ — источник для file.copy в выбранную директорию сайта (#dir#)
data/config/urlrewrite.php — источник для urlrewrite.add
data/config/.option.config.php, .usergroup.config.php, .iblocktype.config.php — источники для data.import.file
data/iblock/*.zip — набор архивов для iblock.import.archive, где каждый архив сопоставляется с “назначением” (кодом/группой) и сайтом (site = ru)

Правило, которое помогает не ломать мастер при доработках: путь к файлам пакета должен быть стабильным, а изменения в составе пакета должны сопровождаться изменениями в параметрах шагов (особенно для file.copy, data.import.file, iblock.import.archive).