using Rugrid.Sdaid.Notation.Documents;
namespace Rugrid.Sdaid.Epas.Ntr.ChangeRequests
{
/// <summary>
/// Батч замечаний и пожеланий к доработке на втором этапе. Зафиксирован «как есть»;
/// разбор, blast radius и план — не проводились.
/// </summary>
public class DOC_CR_2026_08_19_Etap2Backlog : IChangeRequestDocument
{
public static string _refName = "CR 2026-08-19: доработки этапа 2";
public string Name => "Доработки этапа 2 — список замечаний";
public string Description =>
@"Список доработок, которые надо сделать на этапе 2. Зафиксирован, чтобы не потерять; разбор по пунктам, blast radius и план предстоят.";
public string Version => "0.1";
public string Status => "draft";
public string[] Comments => new string[0];
public static string Source = """
## Источник (как есть)
Список доработок, которые надо сделать на этапе 2:
- "при расчете некоторых зданий появлялась ошибка о том, что верхнее перекрытие и высота здания не могут быть равны. Это не так. Надо поправить" — формулировка заказчика
- проверка условий расчётов — "Во всех расчетах высота и уровень верхнего перекрытия должны быть одинаковыми"
- "вывести тип светильников в лампе(светодиодные, люминесцентные)"
- Поведение модели здания ПС, если Климатический район здания не определён
- при загрузки нового справочника классов энергоэффективности из АИС не удаляются записи справочника, которых в АИС уже нет, а в Сервисе они остались. А оставшиеся записи синхронизируются. В результате может возникать перекрытие диапазонов для разных классов: "обновлённого" и "не удалённого"
""";
public static string Analysis = $$""""
## Разбор
**1. Ошибка «верхнее перекрытие и высота здания не могут быть равны» — требование снято.**
Ошибка возникает, если наличие чердака = «Да» и при этом не выполняется условие
«высота здания больше уровня верхнего перекрытия»: $H > z_{ВП}$. Проверка стоит именно
в ветке «чердак есть» секции `te.attic_wall_area` — при отсутствии чердака она не
применяется, потому что высота чердака в расчёт не входит.
Пример из данных: здание ЗВН ПАО «Россети» / МЭС Центра / Валдайское ПМЭС / Тверицкая —
крыша односкатная, наличие чердака = «Да», высота здания = уровень верхнего
перекрытия = 4,42 м. При таких данных высота чердака равна нулю: чердака, объявленного
в модели, геометрически не существует.
Поведение Сервиса логично: он сообщает об ошибке в данных, а не в расчёте. После
аргументации заказчик снял требование. Правок не требуется.
**4. Климатический район здания не определён.** Замечание охватывает три причины
неправильного поведения: сообщение о следствии вместо причины, отсутствие подстановки
климатического района подстанции и невидимость данных района в интерфейсе.
*Почему сообщаются последствия, а не причина.* Климатический район — характеристика
здания, и в расчёт он приходит не сам, а тремя производными величинами. Данные
отопительного периода — продолжительность, средняя температура наружного воздуха,
скорость ветра — берутся из района, когда источник данных отопительного периода =
«Справочные данные»; широта района определяет выборку записей справочника солнечной
радиации. Если района нет, при сборке входной модели недостающие значения приводятся
к нулю, а широта — к нулю, и выборка солнечной радиации оказывается пустой. Дальше
падают валидаторы секций, которым эти данные нужны: `te.heating_degree_days` — на
правиле $z_{ht} \in [1; 365]$, `te.solar_radiation_by_direction` — на отсутствии
записей справочника по каждой стороне света. Оба сообщения верны, и оба — про следствие.
Отсюда правка: отсутствие климатического района должно проверяться до того, как из
района выводятся значения, и сообщаться как ошибка исходных данных здания. Приведение
отсутствующего значения к нулю — тот же дефект, что и с длиной конька в CR по
четырёхскатным крышам: пустое значение подменяется правдоподобным числом и теряет
причину. Где именно ставить проверку — вопрос архитектуры расчёта: сборка входной
модели знает, что района нет, но не сообщает; валидаторы секций видят только нули.
*Климатический район подстанции.* Связь в данных есть: здание принадлежит
организационному объекту, и если это подстанция, у неё есть собственный климатический
район. Правило «район здания, иначе район подстанции, на территории которой здание
размещается» — предметное, поэтому его место в методике: сейчас там сказано, что данные
отопительного периода и широта берутся из климатического района здания, и про
подстановку не сказано ничего. Реализация ложится на сборку входной модели — туда, где
сейчас читается район здания.
*Данные района не видны в интерфейсе.* Пользователь не может обнаружить, что широта
не задана, до запуска расчёта: он её нигде не видит. Спецификация этого не требует —
в описании полей карточки здания есть строки «Климатический район здания. Широта»
и «Долгота», в карточке подстанции — такие же по району подстанции. В реализации
выводится только наименование района (`building.util.ts`, `substation.util.ts`,
`heating-period.util.ts`), а из климатических величин у подстанции показаны три
параметра отопительного периода, и те скрываются, когда значение пустое. Широты нет
нигде, хотя API её отдаёт (`climateRegionLatitude`).
Расхождение реализации со спецификацией: поля привести в соответствие с описанием
полей, а незаполненное значение показывать как незаполненное, а не прятать — скрытая
строка неотличима от отсутствующего требования.
*Решение.* Принят сценарий, в котором подстановки нет: источник
климатических данных становится явным выбором пользователя — район здания, район
подстанции или собственные значения. Пункт вынесен в отдельный CR
{{SdaidAnchors.RefTo<DOC_CR_2026_09_03_ClimateConditions>()}}, там же разбор,
blast radius и план. Открытые вопросы этого пункта закрыты: подстановки нет
(выбор виден и хранится в модели), а для зданий вне подстанций в списке источников
просто нет варианта «район подстанции».
Остальные пункты не разбирались.
"""";
public static string BlastRadius = """
## Blast radius
Не определён. Структурные связи на затронутые документы будут проставлены при разборе.
""";
public static string Plan = """
## План
Не составлен.
""";
public static string Result = """
## Итог
| Пункт | Статус |
|---|---|
| Ошибка «верхнее перекрытие и высота здания не могут быть равны» | отклонено: требование снято заказчиком, поведение Сервиса признано корректным |
| Проверка условий расчётов («высота и уровень верхнего перекрытия должны быть одинаковыми») | не разобран |
| Вывод типа светильников в лампе | не разобран |
| Поведение модели здания ПС при неопределённом климатическом районе | разобран, вынесен в CR 2026-09-03 «Обработка источников климатических данных»: явный выбор источника климатических данных |
| Неудаляемые записи справочника классов энергоэффективности при загрузке из АИС | не разобран |
""";
}
}