Imported from BaniBaushev/unica-opencode (skills-edt/unica-edt-form-events/SKILL.md). Install upstream with npx skills add BaniBaushev/unica-opencode --skill unica-edt-form-events. Copyright stays with the author.

Модуль формы: события и директивы (EDT)

Назначение

Дисциплина написания и ревью модуля управляемой формы: клиент-серверное разделение, директивы компиляции, бюджет серверных вызовов, параметры формы, подключаемые обработчики. Знаниевый навык с MCP-опорами для инспекции и правки.

Предварительные условия

• Запущенная 1C:EDT с плагином EDT-MCP; проект зафиксирован (см. навык edt-mcp-project-session).
• Общие правила: ../COMMON.md.
• Живая ИБ не требуется (только статическая работа).

MCP routing

• get_metadata_details — события, параметры, элементы формы (замена unica.form.info); объект за формой — по FQN объекта.
• get_module_structure, read_module_source, read_method_source — чтение модуля формы (moduleType='FormModule', formName).
• search_in_code, find_references, go_to_definition, get_symbol_info — навигация по коду.
• write_module_source — правки модуля (searchReplace + expectedHash; contentHash берётся из read_module_source).
• create_metadata — объявление параметра формы (...Form.<F>.Parameter.<P>) и обработчиков (...Handler.<Event>) до чтения/использования их в модуле.
• get_project_errors, revalidate_objects, apply_quick_fix — статическая верификация (замена unica.code.diagnostics).

Core model

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

• Где выполняется — &НаКлиенте, &НаСервере, &НаСервереБезКонтекста уместны в модулях форм и команд; в остальных местах — инструкции препроцессора (std439). Одна директива на процедуру, никогда ноль и никогда две.
• Сколько стоит — одно действие пользователя не должно порождать лишних серверных вызовов из кода конфигурации; отклонение требует названной причины (std487).
• Что получает — параметры формы объявляются на закладке параметров, и ПриСозданииНаСервере читает их напрямую, а не пробует Параметры.Свойство() (std741).
• Как подключён — обработчик, назначенный через УстановитьДействие, несёт префикс Подключаемый_ (std492).

Workflow

1. Реши, на какой стороне должна жить логика, до её написания: нужны БД или объект → сервер; нужен пользователь или визуальное состояние формы → клиент.
2. Инспектируй форму через get_metadata_details (объявленные события, параметры, элементы) и объект за ней.
3. Прочитай существующий модуль (get_module_structure, read_module_source) перед добавлением кода.
4. Посчитай серверные вызовы, которые изменение добавляет на пути одного действия пользователя. Если добавляет хотя бы один — назови причину.
5. Объяви новый параметр формы через create_metadata (...Form.<F>.Parameter.<P>) до чтения его в модуле.
6. Применяй правки модуля через write_module_source, по одному проверяемому шагу; каждая новая процедура — ровно с одной директивой.
7. Статическая верификация: revalidate_objects + get_project_errors; поведение в рантайме (открытие затронутой формы) требует отдельных доказательств.

Design rules

• Не ветвись #Если Сервер / #Если Клиент внутри общего модуля КлиентСервер — контекст выполнения там не определяется надёжно (std439). Раздели на модули Клиент и Сервер с одинаковым именем функции, общую часть держи в КлиентСервер.
• Директива в серверном или клиентском общем модуле — шум; контекст уже зафиксирован.
• Серверная процедура, вызываемая с клиента, помечает параметры Знач; форма не должна экспонировать серверный экспортный метод.
• Стартовые обработчики не должны ходить на сервер. Если неизбежно — передай все параметры одним вызовом и кешируй повторы через модуль с повторным использованием возвращаемых значений (std487, std724); в БСП — ОбщегоНазначенияПереопределяемый.
• Долгая работа — в фоновое задание (std642), а не в более длинный серверный вызов. Маршрут — навык фоновых заданий.
• Форма, которой нужны параметры и которая открывается только из кода, не должна быть основной формой объекта. Если обязана быть основной — проверяй параметры в ПриСозданииНаСервере и бросай исключение с объяснением пользователю (std741).
• Не вызывай обработчик события формы программно. Выдели тело в именованную процедуру и зови её из обоих мест.

Review checklist

• У каждой процедуры модуля формы ровно одна директива компиляции.
• Нет веток препроцессора «клиент vs сервер» внутри модуля КлиентСервер.
• Изменение не добавляет серверный вызов на путь действия без названной причины.
• Каждый читаемый в модуле параметр формы объявлен на закладке параметров — нет probing через Параметры.Свойство() в ПриСозданииНаСервере.
• Обработчики, подключённые через УстановитьДействие, несут префикс Подключаемый_.
• Обработчики событий формы сидят в стандартной области обработчиков, а не-обработчики — нет.
• События записи (ПередЗаписью*, ПриЗаписи*, ПослеЗаписи*) присутствуют только когда главный реквизит — постоянный объект или запись.

Stop rules

• Не клади логику собственного пути записи объекта в модуль формы — она не выполнится при записи объекта из кода (маршрут — навык object-events).
• Не читай необъявленный параметр формы.
• Не раздувай серверный вызов, чтобы избежать фонового задания.

Отличия от оригинала (Unica/DESIGNER)

• Ссылки на reference-файлы платформы заменены встроенным core model; стандарты (std439/487/492/642/724/741) цитируются по номерам, точные формулировки сверяй отдельно — навык не является их источником.
• unica.runtime.execute не используется: рантайм-проверки идут через инструменты запуска EDT (launch, отладка) вне этого навыка.
• Проверка результата — revalidate_objects + get_project_errors.