# Правила работы агента ## Общий принцип Работа ведется этапами. После завершения каждого смыслового этапа агент: - кратко фиксирует, что сделано - предлагает пользователю название коммита - ждет явного подтверждения на коммит - только после подтверждения выполняет `git commit` Коммиты не должны идти бессистемным потоком. Каждый коммит должен визуально читаться по заголовку и сразу показывать: - какой это слой изменений - к какому направлению относится этап - что именно сделано на этом этапе ## Формат названия коммита Формат: ```text <ТИП> - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: <НАЗВАНИЕ ЭТАПА> ``` ## Типы коммитов Использовать верхний уровень по смыслу изменений: - `UI` — если изменения в интерфейсе, текстах, навигации, отображении, UX - `ФУНКЦИИ` — если изменения в прикладной логике, API, действиях, синхронизации, обработчиках - `АРХ` — если изменения в архитектуре, структуре данных, инфраструктурных правилах, каркасе реализации Если этап затрагивает несколько слоев, выбирать доминирующий. ## Правило предложения коммита После каждого завершенного этапа агент должен предлагать пользователю готовое название коммита. Перед предложением названия коммита агент должен отдельным коротким блоком указывать следующую задачу. Порядок вывода в конце этапа: - что сделано - следующая задача - предлагаемое название коммита Пример: ```text Следующая задача: добрать source-side индикатор изменений в списке внешних контуров UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур ``` Пользователь отвечает подтверждением в духе: - `коммитить` - `да, коммить` - `ок, коммит` Только после этого агент делает коммит. ## Примеры ```text UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: создание запроса в целевой проект ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: синхронизация статусов источника и цели АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: каркас source-target связи АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: регламент этапов и именования коммитов ``` ## Дополнение Если пользователем не сказано иное: - не делать `amend` - не переписывать историю - не объединять несколько отдельных этапов в один коммит постфактум ## Публикация фронта После каждой правки интерфейса агент должен: - залить изменения на локально доступный frontend - сообщить пользователю, по какому URL смотреть результат - не считать этап завершенным, пока пользователь не сможет открыть измененную страницу в браузере, если этому не мешают внешние технические ограничения