NODEDC_TASKMANAGER/AGENTS.md

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

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

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

После завершения каждого смыслового этапа агент:

• кратко фиксирует, что сделано
• предлагает пользователю название коммита
• ждет явного подтверждения на коммит
• только после подтверждения выполняет git commit

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

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

• какой это слой изменений
• к какому направлению относится этап
• что именно сделано на этом этапе

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

Формат:

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

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

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

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

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

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

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

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

Порядок вывода в конце этапа:

• что сделано
• следующая задача
• предлагаемое название коммита

Пример:

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

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

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

• коммитить
• да, коммить
• ок, коммит

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

Примеры

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

Дополнение

Если пользователем не сказано иное:

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