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