Эталонная норма и эталонный расход топлива

1. Источник (как есть)

Эталонная норма: расчёт эталонной нормы как минимальной базовой нормы по группе ТС Вида ТС и Вида Топлива; Вывести её отдельно в окне подбора модификаций, сохранить, показать в карточке ТС рядом с базовой нормой. Расчёт эталонного расхода: тот же алгоритм, что и для нормативного расхода, с той разницей, что вместо базовой нормы передаётся эталонная норма. Результат показать в карточке ТС, сохранить в VehicleCalc. Показать эталонный расход в реестре ТС рядом с нормативным.

2. Разбор

1. Эталонная норма \(H_эт\) — свойство базовой группы, не отбора. Базовая группа строится правилом 2 Подбор группы модификаций ТС (раздел «Базовая группа»): все модификации вида ТС с установленной нормой, мягко суженные по виду топлива. \(H_эт\) — минимум этой же «установленной нормы» (поле решает OQ_BaseNorm, то же, что и для \(H_s\)) по всей базовой группе, а не по «Отобранным». Отсюда следствие: в отличие от \(H_min\)/\(H_max\)/\(H_s\), которые пересчитываются при любом изменении «Отобранных» (Окно подбора модификаций, правило 5), \(H_эт\) не меняется от действий пользователя со списками в открытом окне — только от смены вида ТС или вида топлива самого ТС (а значит — от пересборки базовой группы при открытии окна или при обновлении из АИС).
2. Храним по аналогии с \(H_s\). \(H_эт\) не хранится как отдельная НСИ-величина справочника и не кэшируется отдельно от расчёта: она вычисляется при открытии окна подбора (показ) и сохраняется в Расчёт ТС по кнопке «Применить» — в тот же момент и тем же действием, что и \(H_min\)/\(H_max\)/\(H_s\) (Окно подбора модификаций, правило 8). Это решение этой сессии: явно не заводим отдельного постоянного хранилища «эталонной нормы вида ТС и топлива» вне расчёта конкретного ТС — его нет и у базовой нормы.
3. Эталонный расход — тот же алгоритм, параметризованный источником нормы, не дубликат формул. Методика расчёта расхода топлива запускается второй раз с тем же входом, кроме одной замены: везде, где ветка использует базовую норму \(H_s\) (fuel.q_mileage и производные от неё в ветках fuel.passenger_car/fuel.bus/fuel.truck/fuel.dump_truck/fuel.special_vehicle), подставляется \(H_эт\). Описываем это не вторым набором секций-формул (нарушило бы правило одного факта), а новой секцией fuel.reference_consumption, которая ссылается на существующие секции веток и явно называет единственное отличие — вход fuel.base_norm заменён на fuel.reference_norm.
4. Объём результата — по требованию, не полный набор промежуточных итогов. В карточке и реестре показывается только итоговый эталонный расход \(Q_эт\) (аналог \(Q_н\)) — как и просил пользователь («результат показать», «показать рядом с нормативным», в единственном числе). Промежуточные эталонные \(Q_эт^зима\), \(Q_эт^гор\) и т. п. не вводятся отдельными полями — решение явно зафиксировано, можно пересмотреть отдельным CR, если понадобится детализация.

3. Blast radius

3.1. Спецификация

3.2. Прототип

4. План

1. Спецификация: ModificationGroupSelection.cs, NtsCalc.cs, InputModel.cs, OutputModel.cs, VehicleCalc.cs, ModificationSelectionModal.cs, VehicleCard.cs, VehicleRegistry.cs.
2. Прототип: shell.js (вычисление, расчёт, реестр), vehicle-card.html, vehicle-registry.html.
3. Собрать (dotnet build, build-html.cmd).
4. doc/testovich проверяют соответствие (отдельный проход, не этой задачей).
5. Зафиксировать «Итог».

5. Acceptance criteria

• AC-1. Окно подбора модификаций показывает эталонную норму \(H_эт\) в итоговой строке, рядом с \(H_min\)/\(H_max\)/\(H_s\); значение не меняется при изменении «Отфильтрованных»/«Отобранных», только при смене вида ТС или вида топлива ТС.
• AC-2. «Применить» сохраняет \(H_эт\) в расчёте ТС вместе с \(H_s\).
• AC-3. Карточка ТС показывает эталонную норму рядом с базовой нормой и эталонный расход рядом с нормативным; при пустой базовой группе — прочерк.
• AC-4. Реестр ТС показывает колонку «Эталонный расход, л» рядом с «Нормативный расход, л».
• AC-5. Эталонный расход считается тем же алгоритмом веток категорий ТС, что и нормативный, с единственной заменой — \(H_s\) на \(H_эт\) во входе fuel.q_mileage (и производных).

6. Итог

Выполнено полностью. Спека и прототип приведены в соответствие: домен, методика, backend-модели, три UI-документа и прототип (shell.js, vehicle-card.html, vehicle-registry.html, сгенерированный modification-selection.html).

doc нашёл и исправлены 3 находки: не заявленная в blast radius связь на EPIC_NtsFuelCalc (добавлены OQ-25/OQ-26, но сам эпик не упомянут ни в Links, ни в blast radius — исправлено); голые текстовые упоминания CR/DOC_AisRefreshPolicy в OQ-24/25/26 вместо typed-ссылок (переведены на SdaidAnchors.RefTo); порядок полей ReferenceConsumptionRate/ReferenceNormConsumption в OutputModel.cs/VehicleCalc.cs нарушал правило «итог → вход» (переставлены).

testovich реальным выполнением подтвердил AC-1 (независимость \(H_эт\) от «Отобранных»), AC-2 (сохранение по «Применить»), AC-3 (размещение полей, прочерк при пустой базовой группе), AC-4 (колонка реестра), AC-5 (та же ветка методики, пропорциональность входу в линейных ветках). Нашёл реальный баг: \(H_эт\) ошибочно гасилась в «—» при ЛЮБОЙ ошибке секции fuel (дата начала эксплуатации, регион и т. п.), хотя по спеке (fuel.reference_norm) должна зависеть только от непустоты базовой группы — нарушение архитектурного принципа «у каждой секции свой независимый валидатор» (DOC_CalcValidators). Исправлено в shell.js, computeNorm(): \(H_эт\) теперь выставляется сразу после вычисления, до общей проверки err, и исключена из общего сброса RESULT_FIELDS при ошибке. Исправление подтверждено повторным реальным выполнением на том же ТС (Toyota Camry, b5e22852-..., без даты начала эксплуатации): \(H_эт\) = 4,60 л/100 км вместо «—».