# Правила работы агента

## Общий принцип

Работа ведется этапами.

После завершения каждого смыслового этапа агент:
- кратко фиксирует, что сделано
- предлагает пользователю название коммита
- ждет явного подтверждения на коммит
- только после подтверждения выполняет `git commit`

Коммиты не должны идти бессистемным потоком.

Каждый коммит должен визуально читаться по заголовку и сразу показывать:
- какой это слой изменений
- к какому направлению относится этап
- что именно сделано на этом этапе

## Формат названия коммита

Формат:

```text
<ТИП> - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: <НАЗВАНИЕ ЭТАПА>
```

## Типы коммитов

Использовать верхний уровень по смыслу изменений:

- `UI` — если изменения в интерфейсе, текстах, навигации, отображении, UX
- `ФУНКЦИИ` — если изменения в прикладной логике, API, действиях, синхронизации, обработчиках
- `АРХ` — если изменения в архитектуре, структуре данных, инфраструктурных правилах, каркасе реализации

Если этап затрагивает несколько слоев, выбирать доминирующий.

## Правило предложения коммита

После каждого завершенного этапа агент должен предлагать пользователю готовое название коммита.

Перед предложением названия коммита агент должен отдельным коротким блоком указывать следующую задачу.

Порядок вывода в конце этапа:
- что сделано
- следующая задача
- предлагаемое название коммита

Пример:

```text
Следующая задача:
добрать source-side индикатор изменений в списке внешних контуров

UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур
```

Пользователь отвечает подтверждением в духе:
- `коммитить`
- `да, коммить`
- `ок, коммит`

Только после этого агент делает коммит.

## Примеры

```text
UI - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: переименование модуля во внутренний контур
ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: создание запроса в целевой проект
ФУНКЦИИ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: синхронизация статусов источника и цели
АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: каркас source-target связи
АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: регламент этапов и именования коммитов
```

## Дополнение

Если пользователем не сказано иное:
- не делать `amend`
- не переписывать историю
- не объединять несколько отдельных этапов в один коммит постфактум

## Ведение карточек задач Codex

Карточка задачи должна разделять постановку и ход работ.

Основное тело карточки:
- хранит общее описание задачи, цель, контекст, ограничения и критерии приемки
- не превращается в журнал работ
- остается читаемым входом в задачу после нескольких итераций

Подэлемент `Текущий статус работ`:
- создается как текстовый блок через `Добавить подэлемент`
- хранит фактический отчет по реализации
- обновляется после каждого осмысленного этапа
- фиксирует, что сделано, что проверено, какие файлы/модули затронуты, что осталось и какой следующий шаг

Подэлемент-чекер:
- используется для подзадач, которые можно проверить отдельно
- содержит короткие конкретные пункты без дублирования основного описания
- закрывается по факту реализации и проверки, а не по намерению

Статус карточки:
- `В работе` ставится только когда задача реально взята в исполнение
- `Готово` ставится после проверки результата
- `Отложено` используется для задач, которые больше не входят в текущий рабочий план
- backlog не должен хранить уже сделанные или сознательно отложенные задачи как активные

## Публикация фронта

После каждой правки интерфейса агент должен:
- залить изменения на локально доступный frontend
- сообщить пользователю, по какому URL смотреть результат
- не считать этап завершенным, пока пользователь не сможет открыть измененную страницу в браузере, если этому не мешают внешние технические ограничения