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

This commit is contained in:
DCCONSTRUCTIONS 2026-04-18 20:04:24 +03:00
parent 55a3b89d11
commit a59f09e2f0
1 changed files with 70 additions and 0 deletions

70
AGENTS.md Normal file
View File

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