Skip to content

AGENTS.md

Latest commit

 

History

History
68 lines (48 loc) · 4.23 KB

AGENTS.md

File metadata and controls

68 lines (48 loc) · 4.23 KB
Raw

AGENTS.md

Инструкции для coding agents, работающих в этом репозитории.

Обязательный стиль работы: TDD

Работать нужно в стиле Test-Driven Development. Любое изменение поведения должно выполняться маленькими итерациями по циклу:

  1. Red — сначала описать ожидаемое поведение тестом.
  2. Запустить релевантный тест и убедиться, что он падает по ожидаемой причине.
  3. Green — внести минимальную реализацию, достаточную для прохождения теста.
  4. Запустить тесты и убедиться, что они проходят.
  5. Refactor — аккуратно улучшить код, не меняя поведения.
  6. Повторять цикл до завершения задачи.

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

Как писать тест-кейсы

Перед реализацией нужно грамотно сформулировать тест-кейсы:

  • для багов — сначала добавить регрессионный тест, воспроизводящий проблему;
  • для новых функций — покрыть основной сценарий, важные edge cases и ошибки;
  • для изменения UX/TUI — проверять состояние модели, ключевые строки рендера и пользовательские сценарии ввода;
  • для storage/config/sync — проверять реальные переходы состояния через публичные API, используя изолированное окружение/temporary data;
  • использовать table-driven tests там, где есть несколько однотипных случаев;
  • избегать хрупких тестов, завязанных на несущественные детали форматирования;
  • имена тестов должны описывать поведение, а не внутреннюю реализацию.

Итерационный процесс

Не делать большие изменения одним куском. Работать маленькими проверяемыми шагами:

  1. Уточнить ожидаемое поведение.
  2. Найти ближайший уровень тестирования: unit, integration, CLI/TUI model.
  3. Добавить минимальный тест.
  4. Запустить целевые тесты.
  5. Исправить код.
  6. Запустить целевые тесты снова.
  7. В конце запустить полный набор:
go test ./...

Если полный набор тестов не запускается или падает по внешней причине, нужно явно указать это в финальном ответе.

Проектные команды

Основная проверка:

go test ./...

Форматирование Go-кода:

gofmt -w <files>

Качество изменений

  • Сохранять существующее поведение, если задача явно не требует обратного.
  • Для каждого исправленного бага оставлять тест, который предотвратит регрессию.
  • Не удалять и не ослаблять тесты без явной причины.
  • Предпочитать простую реализацию сложной, пока тесты не требуют большего.
  • После refactor-фазы обязательно повторно запускать тесты.