---
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-godog` и `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`

Пример:

```go
func TestLogin_InvalidPassword(t *testing.T) {
	user := createUser(t, "user@example.com", "correct")
	_, err := service.Login(ctx, "user@example.com", "wrong")
	require.ErrorIs(t, err, ErrInvalidCredentials)
}
```

```gherkin
Scenario: 02_reject_invalid_password
  Given зарегистрирован пользователь "user@example.com"
  When пользователь вводит "user@example.com" и неверный пароль
  Then система отвечает ошибкой "неверные учётные данные"
```

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

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

#### Git history

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

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

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

#### Интервью

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

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

- `Arrange / Act / Assert` из тестов превращаются в `Given / When / Then`
- технические сущности переводятся на бизнес-язык
- скрытые правила и регрессии становятся отдельными сценариями

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

- naming, numbering и структура файла проверяются по `x-bdd-godog`
- готовность черновика к 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-godog`

## Смежные skills

- `x-bdd-godog`
- `x-bdd-product-workflow`
- `x-bdd-dev-workflow`
- `x-doc-go`