Обещание точности лендинга измерялось только на екатеринбургских ДКП: скрипт
бэктеста не имел параметра региона (region_code был зашит числом 66), а сам
SELECT сделок вообще не фильтровал по deals.region_code. Пока в базе жил
только регион 66, это было незаметно — но теперь там же лежат 212 937
московских ДКП (69 138 за последние 12 мес.) и 113 351 подмосковных, и
безусловный "unscoped" запрос молча смешал бы все три региона в одной
выборке. Прогон по Москве до этой правки сделать было нечем.
Добавлен CLI-флаг --region (по идиоме app/tasks/msk_raw_import.py: явный
список поддерживаемых значений, отказ на неизвестном коде ДО любого запроса
к БД). Источник допустимых значений — реестр REGIONS из
app/services/regions.py, а не отдельный литерал: регион заводится в реестре
один раз и становится доступен здесь автоматически. Дефолт оставлен 66 —
поведение существующих вызовов не меняется.
region_code проведён во все 4 варианта SQL выборки сделок (обычная/scattered
× city/no-city) и в per-city PPM2-band lookup (_resolve_city_ppm2_band).
Отдельно поправлен _predict_full_spine: ДКП-коридор (_fetch_dkp_corridor)
резолвил регион только по умолчанию (66) независимо от сделки — теперь
регион резолвится ПО КООРДИНАТАМ каждой сделки через regions.region_for_point,
зеркаля то, как это делает сам prod-эстиматор (estimator.py ~4868-4870).
Без этого фикса флаг --region был бы декоративным: SELECT сделок брал бы
верный регион, но коридор аналогов всё равно считался бы по Свердловской
области.
Проверено: --help показывает --region {50,66,77}; --region 99 отклоняется
argparse ДО подключения к БД (exit 2); ruff check/format check чисты; все
83 существующих теста backtest_* проходят без изменений.
Полный прогон по Москве в этой задаче не запускался (долгий, отдельная
проверка): python -m scripts.backtest_estimator --region 77 --since
2024-09-01 --sample 300
