x-bdd-knowledge-harvest

name	x-bdd-knowledge-harvest
description	Применяй для конвертации фрагментарных legacy-знаний (код, doc.go, docs/, git history, интервью) в структурированные .feature файлы

BDD Knowledge Harvest

Этот skill — канонический владелец reverse-engineering потока: как извлекать бизнес-сценарии из существующего кода и документов.

Он не владеет layout/naming .feature и не владеет dev RGB-циклом. За это отвечают x-bdd-api и x-bdd-dev-workflow.

Когда применять

• Репозиторий уже работает, но BDD-описания отсутствуют или фрагментарны.
• Нужно зафиксировать текущее наблюдаемое поведение перед рефакторингом.
• Бизнес-правила размазаны между кодом, doc.go, docs/, git history и знаниями команды.

Не применяй для:

• новых фич с нуля → x-bdd-product-workflow
• технической документации пакета → x-doc-go
• реализации шагов и production-кода → x-bdd-dev-workflow

Core workflow

1. Зафиксируй scope harvest

Выбери модуль, поток или пользовательскую задачу. Цель — восстановить бизнес-наблюдаемое поведение, а не переписать устройство системы.

2. Иди по источникам в стабильном порядке

Рекомендуемый порядок:

1. doc.go и публичные API
2. существующие *_test.go
3. docs/ и другие текстовые артефакты
4. git history
5. интервью с носителем знаний

doc.go и публичные API

• публичная функция или хэндлер может быть кандидатом в Feature
• описание пакета помогает собрать user story
• технический контракт остаётся в doc.go; в .feature уходит только наблюдаемое поведение

Существующие тесты

Правило трансляции:

• Arrange → Given
• Act → When
• Assert → Then

Пример:

func TestLogin_InvalidPassword(t *testing.T) {
	user := createUser(t, "[e-mail]", "correct")
	_, err := service.Login(ctx, "[e-mail]", "wrong")
	require.ErrorIs(t, err, ErrInvalidCredentials)
}

Scenario: 02_reject_invalid_password
  Given зарегистрирован пользователь "[e-mail]"
  When пользователь вводит "[e-mail]" и неверный пароль
  Then система отвечает ошибкой "неверные учётные данные"

docs/ и markdown-артефакты

• FAQ часто даёт готовые альтернативные сценарии
• changelog и how-to описывают скрытые правила
• фразы вида «если X, то Y» обычно превращаются в отдельный Scenario

Git history

• bugfix-коммиты дают регрессионные сценарии
• feature-коммиты показывают эволюцию правил

Полезные команды:

git log --grep="fix" --oneline --all
git show <sha>
git log --follow path/to/file.go

Интервью

Спрашивай:

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

3. Переводи наблюдения в бизнес-сценарии

• Arrange / Act / Assert из тестов превращаются в Given / When / Then
• технические сущности переводятся на бизнес-язык
• скрытые правила и регрессии становятся отдельными сценариями
• результат сохраняется в features/NN_epic/NN_story.feature
• в monorepo проставляй один execution tag на сценарий: @api или @browser; политику выбора канала смотри в x-bdd-api
• в backend-only/frontend-only execution tags не добавляй без отдельной причины
• если тип проекта или канал исполнения неясен, фиксируй вопрос, а не выбирай @api по умолчанию
• если legacy намекает на @api @browser, фиксируй вопрос или разделяй intent вместо автоматического двойного тега

4. Сверяй результат с BDD-конвенциями

• naming, numbering и структура файла проверяются по x-bdd-api
• готовность черновика к handoff проверяется по x-bdd-product-workflow

5. Зафиксируй baseline перед изменениями

Harvest лучше завершать до крупного рефакторинга. Тогда полученный .feature становится контрактом текущего поведения, а дальнейшая реализация уходит в x-bdd-dev-workflow.

Антипаттерны

• конвертировать в .feature каждый unit-тест подряд
• слепо копировать changelog без восстановления пользовательского эффекта
• делать harvest уже после рефакторинга
• оставлять SQL, endpoint names и internal errors в шагах

Короткий чек-лист

• выбрана узкая область harvest
• каждый источник дал новые, а не дублирующие сценарии
• технические детали не протекли в шаги
• пробелы закрыты интервью или явно отмечены как вопросы
• итоговый .feature готов к проверке по x-bdd-api

Смежные skills

• x-bdd-api
• x-bdd-browser
• x-bdd-product-workflow
• x-bdd-dev-workflow
• x-doc-go