# Решения

## D-001. Модель переключения отрасли

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - уровень облачного развертывания (`master/tenant cloud`) поддерживает несколько отраслей;
  - уровень площадки/шкафа (`site/cabinet edge`) использует только одну отрасль применения.
- Техническая модель:
  - cloud: multi-industry registry и маршрутизация по `industry_code`;
  - edge: фиксированный `industry_code` на инсталляцию (без runtime-переключения).
- Влияние: модель данных, права, UI-навигация, профиль деплоя.

## D-002. Гранулярность отраслевых модулей

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - отрасль реализуется как **набор модулей**, а не монолит;
  - на конкретном хозяйстве/площадке включается только нужный поднабор;
  - каждый модуль имеет **одну ключевую сущность** (domain owner);
  - модуль может агрегировать/обогащать данные других модулей, но не забирает их ownership.
- Пример (poultry):
  - `industry.poultry.climate` -> ключевая сущность `climate_profile`;
  - `industry.poultry.flock` -> ключевая сущность `batch`;
  - `industry.poultry.feedwater` -> ключевая сущность `feedwater_snapshot`;
  - `industry.poultry.production` -> ключевая сущность `production_kpi`.

## D-003. Политика нормативов

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - нормативы хранятся в конфигурационных профилях (не в коде);
  - профиль должен быть переносим между хозяйствами через выгрузку/загрузку `YAML`;
  - изменения профилей версионируются;
  - поддерживается откат профиля на предыдущую версию.
- Обязательные функции:
  - `export profile -> yaml`;
  - `import yaml -> validate -> draft`;
  - `publish version`;
  - `rollback to version`.
- Влияние: высокая скорость адаптации под генетику/регион/сезон, контролируемость изменений.

## D-004. Контуры ответственности для тревог

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило: **вариант B**.
  - общий `status` остается единым системным контуром;
  - специализированные тревоги отрасли публикуются в отдельный `industry alarm-bus`.
- Правило маршрутизации:
  - критические отраслевые тревоги дублируются в `status` как агрегированные события;
  - детальная диагностика и эскалация остаются в отраслевом контуре.
- Влияние: сохраняется единая операторская видимость через `status`, при этом не теряется отраслевая детализация.

## D-005. Приоритет отраслей после poultry

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - следующая отрасль после `poultry` — `melioration` (мелиорация).
- Обязательный состав модулей melioration:
  - `industry.melioration.field` (ключевая сущность: `field_water_balance`);
  - `industry.melioration.irrigation_machine` (широкозахватные дождевальные машины);
  - `industry.melioration.irrigation_drip` (капельное/внутрипочвенное орошение);
  - `industry.melioration.soil_moisture` (мониторинг влажности почвы);
  - `industry.melioration.weather` (локальная метеостанция + внешние погодные интеграции).
- Правило обогащения:
  - модуль `field` агрегирует данные об объеме и источнике воды:
    - от дождевальных машин;
    - от внутрипочвенного/капельного орошения;
    - от осадков (метеостанция и/или внешние сервисы).

## D-006. Источник нормативов для poultry

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - источники из `docs/industries/poultry/source-instructions.md` считаются source-of-truth для MVP poultry;
  - обязательное baseline-ядро нормативов:
    - `Ross-BroilerHandbook2018-RU.pdf`;
    - `ARBOR_Вентиляция.pdf`;
    - `xajseks-braun-rukovodstvo.pdf`;
  - контроллерные документы (`Climatepro`, `AC Touch`, `99-94-0635`) используются как source-of-truth по operational/alarm паттернам.
- Влияние: KPI, алармы, алгоритмы климат-контроля и профили уставок.

## D-007. Единица учета воды в melioration

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - использовать модель **C**: хранить обе единицы;
  - `mm` является primary-значением для агрономических расчетов и нормативов;
  - `m3` хранится как derived/операционное значение (с привязкой к площади поля/зоны).
- Влияние: совместимость отчетности, расчеты норм полива, сравнение источников.

## D-008. Приоритет источника осадков в melioration

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - локальная метеостанция является primary-источником осадков;
  - внешний weather service используется как fallback при пропусках/недоступности локальной станции;
  - расхождения локального и внешнего источников используются для контроля аномалий.
- Влияние: точность водного баланса и доверие операторов.

## D-009. Режим управления поливом в MVP

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - базовый режим MVP: **B** (`semi-auto`, рекомендации + подтверждение оператором);
  - поддерживается переключение режима в **A** (`advisory-only`) и **C** (`full-auto`);
  - переключение режима выполняется только через конфигурацию с аудитом изменений.
- Ограничения безопасности:
  - режим **C** разрешается только при валидном профиле правил и исправных источниках телеметрии;
  - при потере критичных данных система должна автоматически деградировать из `C` в `B` или `A` по policy.
- Влияние: безопасность внедрения, скорость реакции, ответственность эксплуатации.

## D-010. Приоритет отрасли после melioration

- Статус: **РЕШЕНО** (2026-03-05).
- Принятое правило:
  - следующая отрасль после `melioration` — `swine` (свиноводство).
- Обоснование:
  - есть пересечение по климат-контролю и тревогам с уже покрытыми платформенными контрактами;
  - позволяет переиспользовать паттерны модульной декомпозиции (`climate`, `feeding`, `water`, `production`, `biosecurity`);
  - снижает риск запуска третьей отрасли за счет доступной базы нормативных источников и операционных практик.
- Влияние:
  - запускается пакет `docs/industries/swine` как следующий отраслевой контур;
  - задачи и критерии приемки по `swine` ведутся в отдельном отраслевом backlog.

## D-011. Представление poultry-модулей во frontend

- Статус: **РЕШЕНО** (2026-03-06).
- Принятое правило:
  - poultry во frontend представляется как единый workspace `Птицеводство`;
  - внутри workspace сохраняются изолированные submodule-экраны (`climate`, `flock`, `feedwater`, `production`, `alarms`);
  - `cloud/tenant` использует overview dashboard как primary-вход;
  - `edge-single` использует тот же poultry-dashboard как основной fullscreen cards-экран для 10" HMI;
  - отдельный canvas-режим не используется;
  - primary drill-down выполняется через карточки dashboard и переход в модульные детали.
- Ограничения:
  - `poultry-profiles/*` не выводятся как основной пользовательский модуль;
  - состав submodule-ов остается управляемым через install state и `site-policy`.
- Влияние:
  - frontend shell получает workspace-level навигацию;
  - edge-контур получает уплотненный fullscreen cards-layout без отдельной второй визуальной модели.

## D-012. Пакет `weighbridge` в published industry layer

- Статус: **РЕШЕНО** (2026-03-12).
- Принятое правило:
  - `weighbridge` фиксируется как отдельный отраслевой пакет published-слоя, а не остается только в `docs/featurelists/*` и `docs/company/*`;
  - пакет синхронизируется с reference runtime `../ioot-pro-cabinet`, где уже заведены модули `weighbridge-session`, `weighbridge-identity`, `weighbridge-media`, `weighbridge-alarms` с `industry_code=weighbridge`;
  - edge ANPR/device контур для этого пакета ведется в отдельном engineering repo `../ioot-pro-anpr`.
- Обоснование:
  - работа по беспилотным весам уже идет как отдельный runtime-контур, поэтому отсутствие пакета в `docs/industries/*` искажает фактический срез платформы;
  - published-контур уже содержит прикладной смысл весов в `featurelists` и `company`, но ему не хватало явного отраслевого пакета.
- Влияние:
  - в `green-robot` появляется отдельный пакет `docs/industries/weighbridge`;
  - отраслевой обзор, project map и registration-facing runtime registry должны учитывать `weighbridge` как активную часть платформы.