recommend_mix v3.3: hard-cap window 24 мес + предупреждение о свежести данных #24

New issue

Closed

opened 2026-05-10 14:19:59 +00:00 by lekss361 · 2 comments

lekss361 commented

2026-05-10 14:19:59 +00:00

(Migrated from github.com)

Контекст

Сейчас months_window в recommend_mix поднят до 24 (после Sprint 1 audit), но через API его всё ещё можно передать любым (36, 48, …). Юзер указал что данные старше 2 лет нерелевантны — слишком сильно влияют внешние факторы и финансовые инструменты (ставки ЦБ, эскроу, льготная ипотека, СВО, etc.).

Нужно:

Hard-cap на бэке: max 24 месяца, даже если фронт передал больше.
Предупреждение в UI: «данные за 24 месяца, более старые исключены — внешние факторы (ставки, программы) сильно отличались».
Пересмотреть elasticity_window_months (сейчас 36 — нужно тоже снизить).

Что делать

Backend

В analytics_queries.recommend_mix (и связанных функциях): months_window = min(months_window, 24) с warning в logs если был передан больше.
Аналогично elasticity_window_months: hard-cap 24 (сейчас 36, что является open issue B3 из аудита).
Синхронизировать оба окна — теперь они одинаковые. Удалить рассинхрон-комментарий из scope.
В scope добавить data_freshness_warning: true если попавшие в окно данные старше 24 мес (не должно быть после hard-cap, но safety check).

Frontend

На /analytics/recommend — статичный badge «📅 учтены данные за последние 24 месяца» рядом с заголовком.
Если в форме можно было выбрать 36 — убрать опцию (или disable).
Tooltip объясняющий почему 24 а не больше (ставки ЦБ + ипотечные программы за 2 года менялись радикально).

Acceptance

В API response scope.share_window_months == 24 == scope.elasticity_window_months.
При попытке передать 36 в API — backend возвращает 200 с warning в логах, а фактически использует 24.
В UI всегда виден badge «24 мес».

Зависит от

Sprint 1 audit fix B1 (already done — default 24)
Sprint 1 audit fix B3 (open — синхронизировать окна)

Live verification

Открыть /analytics/recommend, проверить: в headline нет упоминания старше 2024-05; в API response (network tab) elasticity_window_months == 24.

## Контекст Сейчас `months_window` в `recommend_mix` поднят до 24 (после Sprint 1 audit), но через API его всё ещё можно передать любым (36, 48, …). Юзер указал что **данные старше 2 лет нерелевантны** — слишком сильно влияют внешние факторы и финансовые инструменты (ставки ЦБ, эскроу, льготная ипотека, СВО, etc.). Нужно: 1. Hard-cap на бэке: max 24 месяца, даже если фронт передал больше. 2. Предупреждение в UI: «данные за 24 месяца, более старые исключены — внешние факторы (ставки, программы) сильно отличались». 3. Пересмотреть `elasticity_window_months` (сейчас 36 — нужно тоже снизить). ## Что делать ### Backend - [ ] В `analytics_queries.recommend_mix` (и связанных функциях): `months_window = min(months_window, 24)` с warning в logs если был передан больше. - [ ] Аналогично `elasticity_window_months`: hard-cap 24 (сейчас 36, что является open issue B3 из аудита). - [ ] Синхронизировать оба окна — теперь они одинаковые. Удалить рассинхрон-комментарий из scope. - [ ] В scope добавить `data_freshness_warning: true` если попавшие в окно данные старше 24 мес (не должно быть после hard-cap, но safety check). ### Frontend - [ ] На `/analytics/recommend` — статичный badge «📅 учтены данные за последние 24 месяца» рядом с заголовком. - [ ] Если в форме можно было выбрать 36 — убрать опцию (или disable). - [ ] Tooltip объясняющий **почему** 24 а не больше (ставки ЦБ + ипотечные программы за 2 года менялись радикально). ## Acceptance - В API response `scope.share_window_months == 24 == scope.elasticity_window_months`. - При попытке передать 36 в API — backend возвращает 200 с warning в логах, а фактически использует 24. - В UI всегда виден badge «24 мес». ## Зависит от - Sprint 1 audit fix B1 (already done — default 24) - Sprint 1 audit fix B3 (open — синхронизировать окна) ## Live verification Открыть `/analytics/recommend`, проверить: в headline нет упоминания старше 2024-05; в API response (network tab) `elasticity_window_months == 24`.

lekss361 commented

2026-05-10 14:20:57 +00:00

(Migrated from github.com)

Часть пакета recommend_mix v3: см. #22 #23 #25. Делать первой — самая дешёвая (~1 час), отвязывает все остальные от рисков использования старых данных.

Часть пакета **recommend_mix v3**: см. #22 #23 #25. **Делать первой** — самая дешёвая (~1 час), отвязывает все остальные от рисков использования старых данных.

lekss361 commented

2026-05-11 19:24:14 +00:00

(Migrated from github.com)

Реализовано в commit c31da62.

Что добавлено:

Hard-cap months_window = min(months_window, 24) с logger.warning при попытке >24
Pydantic RecommendMixInput.months_window: le=36 → le=24
SQL для elasticity параметризован: (:ew || ' months')::interval (было захардкожено '36 months')
scope: share_window_months == elasticity_window_months == 24 (синхронизированы)
Frontend MONTHS_OPTIONS: [12, 18, 24, 27] → [12, 18, 24] (убрана 27 мес)

Verification: {share_window_months: 24, elasticity_window_months: 24} в API response.

Frontend (RecommendForm.tsx): Badge 📊 Данные: последние 24 месяца с tooltip про макро-контекст (ЦБ ставка, льготная ипотека).

Реализовано в commit c31da62. **Что добавлено:** - Hard-cap `months_window = min(months_window, 24)` с logger.warning при попытке >24 - Pydantic `RecommendMixInput.months_window`: `le=36` → `le=24` - SQL для elasticity параметризован: `(:ew || ' months')::interval` (было захардкожено `'36 months'`) - scope: `share_window_months == elasticity_window_months == 24` (синхронизированы) - Frontend MONTHS_OPTIONS: `[12, 18, 24, 27]` → `[12, 18, 24]` (убрана 27 мес) **Verification:** `{share_window_months: 24, elasticity_window_months: 24}` в API response. **Frontend (RecommendForm.tsx):** Badge `📊 Данные: последние 24 месяца` с tooltip про макро-контекст (ЦБ ставка, льготная ипотека).