6.3 KiB

Raw Blame History

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

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

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

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

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

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

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

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

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

Формат:

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

Примеры

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

Дополнение

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

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

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

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

Основное тело карточки:

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

Подэлемент Текущий статус работ:

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

Подэлемент-чекер:

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

Статус карточки:

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

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

После каждой правки интерфейса агент должен:

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

6.3 KiB Raw Blame History Unescape Escape