# Сценарии E2E

Документ задает целевые end-to-end сценарии для poultry-кейсов на уровне бизнес-потока.

## 1. Scope

- Контур: `poultry.broiler`, `poultry.layer`.
- Модули: `climate`, `flock`, `feedwater`, `production`, `alarms`.
- Системные зависимости: `status`, `modules`, `app/context`, `industry alarm-bus`.

## 2. Общие предусловия

- Активная отрасль в контексте: `poultry`.
- Площадка и птичник заведены (`tenant_id`, `site_id`, `house_id`).
- Включены целевые poultry-модули на площадке (site-policy).
- Создан и опубликован нормативный профиль poultry (минимум `climate + alarms`).
- В тестовом стенде доступны симуляторы источников telemetry (климат, вода, корм).

## 3. Сценарий E2E-BR-01: полный цикл партии бройлера

Цель: подтвердить корректность age/phase-driven управления микроклиматом и тревог.

Шаги:
1. Создать `batch` для `broiler` и привязать age-фазы (`day_1`, `day_7`, `day_21`).
2. Опубликовать профиль `climate_profile` с уставками по фазам.
3. Подать telemetry в нормальном диапазоне для `day_1`.
4. Переключить фазу до `day_7` и проверить обновление целевых setpoint.
5. Подать telemetry с критическим превышением температуры.
6. Проверить создание события в poultry alarm-bus и bridge в `status`.
7. Подтвердить обработку тревоги оператором и восстановление в норму.
8. Проверить расчет KPI цикла (минимум: сохранность, feed conversion proxy).

Критерии приемки:
- Фазовый переход меняет активные уставки без ручного патча профиля.
- Критическое отклонение создает `severity=critical` и `priority=P1`.
- В `status` появляется агрегированное событие с тем же `correlation_id`.
- После нормализации формируется закрывающее/нормализующее событие.

## 4. Сценарий E2E-LY-01: продуктивность несушки

Цель: подтвердить связку программ света/воды/корма с KPI продуктивности несушки.

Шаги:
1. Создать `batch` типа `layer` и профиль световой программы.
2. Подать baseline telemetry по климату, воде и корму.
3. Записать производственные данные смены (яйценоскость, процент брака).
4. Смоделировать снижение водопотребления ниже порога.
5. Проверить генерацию тревоги `high`/`medium` (по policy) и создание задачи оператору.
6. Выполнить корректирующее действие и повторно подать telemetry.
7. Проверить восстановление KPI до целевого диапазона.

Критерии приемки:
- KPI продуктивности рассчитываются на окне смены/суток.
- Аномалия воды/корма вызывает тревогу по согласованному правилу.
- Действия оператора отражаются в аудите и влияют на следующую оценку KPI.

## 5. Данные и фикстуры

- Базовые фикстуры:
  - `tenant_id=tenant-e2e-poultry`
  - `site_id=site-e2e-01`
  - `house_id=house-a1`
  - `industry_code=poultry`
- Наборы данных:
  - `telemetry_normal.json`
  - `telemetry_heat_stress.json`
  - `telemetry_feedwater_anomaly.json`
  - `production_shift_layer.json`

## 6. Наблюдаемость и артефакты прогона

- Для каждого прогона сохранять:
  - логи запросов API (ключевые endpoint-ы);
  - снимки `status/list` и poultry alarm-list;
  - итоговый отчет KPI до/после инцидента;
  - таблицу `step -> expected -> actual`.
- Минимальный отчет по сценарию:
  - `scenario_id`
  - `run_started_at`
  - `result` (`pass|fail`)
  - `failed_step` (если есть)
  - `links` на логи/артефакты.

## 7. Очередь автоматизации

1. Подготовить backend test-fixtures и deterministic seed для poultry.
2. Добавить contract checks envelope/meta/error для poultry endpoint-ов.
3. Собрать Playwright e2e flow:
   - smoke path для `BR-01` (критичный инцидент + восстановление),
   - smoke path для `LY-01` (продуктивность + аномалия).
4. Подключить в CI как nightly `poultry-e2e`.