1238 commits

Author	SHA1	Message	Date
bot-backend	6ffcd78d35	fix(tradein/avito): страница SERP отдаёт 60 карточек, а не 50 ... Замер живьём 2026-08-21 через tradein-browser (camoufox, JS исполняется): 59-60 уникальных `data-item-id` на странице выдачи. «Лишние» сверх 50 — обычные объявления с платным продвижением (`vas-icon_type-promoted`), они лежат в том же списке под `page-title/count`, а не отдельным рекламным блоком, и собираются наравне с остальными. Направление эффекта важно понимать правильно. Константа участвует ТОЛЬКО в `ceil(total / PAGE)`, поэтому занижение размера страницы ЗАВЫШАЛО расчётное число страниц, а не занижало: - запрашивали примерно на 17 % страниц больше, чем нужно; при доле банов 37-83 % по avito-заданиям лишние запросы — основная цена ошибки; - `tail_loss` считался как `total - cap * 50` и завышал потерю; - флаг `complete` в пагинации листа чаще ложно показывал «неполно». Тихой потери данных НЕ было: условия «страница вернула меньше PAGE карточек, значит последняя» в коде нет, пагинация ограничена только `max_pages`. Тест закрепляет и значение, и направление арифметики, чтобы неверная трактовка не вернулась при следующем рефакторинге. Найдено при разборе Авито сверкой живого браузера со скраппером; полный разбор — в волте `research/Avito_Live_Browser_Recon_0821.md`. Refs #3033	2026-08-21 17:38:55 +03:00
bot-backend	fc2930fbb6	Merge remote-tracking branch 'forgejo/main' into fix/3034-avito-fingerprint	2026-08-21 17:27:52 +03:00
bot-backend	7382ae123d	feat(tradein/avito): полный обход качает вторичку родным фильтром пути (#3033) (#3039)	2026-08-21 14:22:48 +00:00
bot-backend	4ec3b79704	fix(tradein/scraper-kit): поднять пол curl-cffi до 0.15.0 — chrome146 в 0.7.0 не существует ... DEFAULT_IMPERSONATE переведён на chrome146, но оба pyproject продолжали объявлять `curl-cffi>=0.7.0`. В 0.7.0 такого профиля нет: установка по нижней границе — и curl_cffi роняет КАЖДЫЙ запрос скраппера на невалидном impersonate, причём одинаково для avito, cian и yandex. На проде стоит 0.15.0 (проверено в контейнере tradein-scraper: профили chrome99 … chrome146 плюс алиас chrome), поэтому текущий деплой бы не пострадал — но любая пересборка окружения с резолвом к нижней границе воспроизвела бы отказ, и диагностировался бы он как «скрапперы легли», а не как несогласованная зависимость. Refs #3034	2026-08-21 17:06:13 +03:00
bot-backend	fe628a5e17	fix(tradein/scraper-kit): actualize avito fingerprint - impersonate/Sec-Fetch-Site/referer/cookie-check ... Живой замер браузера 2026-08-21 разошёлся с тем, что шлёт прогретая сессия: - impersonate="chrome120" был захардкожен в 9+ местах (avito/{serp,detail,imv, houses}.py, pipeline.py x4, cian/valuation.py, yandex/valuation.py) вместо единой DEFAULT_IMPERSONATE (providers/_base.py). Обновление до chrome146 (макс. доступный профиль curl_cffi 0.15.0; alias "chrome" НЕ используется - едет сам при апгрейде библиотеки без ревью) теперь меняется в одном месте. Guard-тест backend/tests/test_impersonate_single_source.py грепает всё дерево scraper_kit на литерал "chrome120". - DOCUMENT_HEADERS ставил Sec-Fetch-Site="none" на уровне сессии, а Referer добавлялся per-request (curl_cffi мёржит per-request headers поверх session-level) - живой Referer с "none" рядом не бывает у настоящего Chrome. Добавлен referer_headers() (Sec-Fetch-Site="cross-site") для caller'ов с чужедоменным Referer; avito warm-up (yandex/ya.ru -> avito) теперь его использует. Внутренний avito-search -> avito-detail Referer (fetch_detail, same-origin) НЕ тронут - отдельный явный комментарий почему. - Referer прогрева заменён с yandex.ru на ya.ru (живой переход из выдачи даёт короткий домен). ysclid сознательно не добавлен - значение выпускает Яндекс, подделка хуже отсутствия. - warm_up_session/research_in_session считали прогрев успешным по HTTP- статусу и отсутствию firewall-маркеров, не проверяя антибот-cookies (__zzatw-*/cfidsw-*, сняты с живого браузера) - detail-батч на такой "прогретой" сессии сжигал прокси на обречённых 403. Теперь поднимают AvitoWarmupCookiesMissingError (наследник AvitoBlockedError - существующие except-блоки/ban_kind/proxy-ротация в pipeline и backfill ловят без изменений). Полный backend pytest suite зелёный (4672 passed), ruff check чист. Refs #3034	2026-08-21 17:02:53 +03:00
bot-backend	4cb8f32dcc	Merge remote-tracking branch 'forgejo/main' into fix/2990-clean-start-initdb	2026-08-21 15:35:32 +03:00
bot-backend	a3ccbbd045	fix(db/ci): 077 гардится по USER MAPPING, деплой ждёт готовности БД по TCP ... Deep-review BLOCK на PR #3011: обе правки чинили заявленный симптом только частично. 077: гард считал pending-строки по source='rosreestr' AND dedup_hash ~ md5-паттерн и пропускал backfill, только если таких строк 0. На чистой БД они есть — 003_seed_deals.sql сеет синтетические сделки с тем же паттерном, значит pending > 0 уже на пустом томе, и миграция всё равно падала на "user mapping not found" (воспроизведено в CI run 8257). Первичный гард теперь проверяет напрямую наличие USER MAPPING для gendesign_remote (идиома из app/core/fdw.py:57-62), счётчик pending оставлен вторым — экономит обращение к FDW, когда мигрировать уже нечего. deploy-tradein.yml: цикл ожидания готовности postgres ходил по unix-сокету (pg_isready без -h). На пустом томе временный init-сервер отвечает на сокете, пока docker-entrypoint-initdb.d ещё прогоняет цепочку миграций — проба зеленела посреди initdb. Добавлен -h 127.0.0.1 (тот же приём уже есть в ci-tradein.yml:157) — TCP открывается только после полного завершения initdb.d. Отдельно ужесточён sentinel baseline-детекции: раньше «схема уже накачена» проверялась одной таблицей listings (миграция 002, почти голова цепочки). Если бы гонка готовности когда-нибудь вернулась, listings был бы уже создан, а хвост цепочки — ещё нет, и baseline тихо пометил бы недостающие миграции применёнными без прогона. Теперь проверяются оба конца — listings (голова) и houses_geog_gist_idx, индекс из миграции 270 (хвост); при несовпадении (ровно один конец на месте) деплой падает громко с explicit ошибкой вместо угадывания.	2026-08-21 15:35:26 +03:00
bot-backend	cdf493f345	chore(format): нормализация под ruff 0.15.20 — 161 файл, только формат (#2864) (#3022)	2026-08-21 12:01:52 +00:00
bot-backend	1782dae0e2	chore(tooling): pre-commit, pyproject и uv.lock — один ruff 0.15.20 (#2864) (#3021)	2026-08-21 11:37:23 +00:00
bot-backend	fa32db299d	feat(db): GiST по (geom::geography) на houses — матчинг идёт по индексу (#2997) (#3020)	2026-08-21 10:24:35 +00:00
bot-backend	bf119de7bb	fix(db): миграция 269 — SET LOCAL lock_timeout внутри BEGIN/COMMIT (#2752) ... Вне транзакции SET LOCAL молча ничего не делает — гейт это ловит, и он поймал меня второй раз подряд, теперь локально, до CI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 14:46:17 +05:00
bot-backend	8de9831e25	fix(db): миграция 269 — SET LOCAL lock_timeout перед ALTER TABLE houses (#2752) ... Гейт CI «блокирующий DDL без lock_timeout» покраснел по делу: ALTER TABLE берёт ACCESS EXCLUSIVE на houses и при живом писателе ждал бы бесконечно, копя очередь. 5с — миграция падает честно и деплой перезапускается. Предыдущий пустой коммит «перезапуск — флуктуация раннера» был ошибкой диагноза: я не дочитал лог changes до ::error и приписал падение checkout'у. Единственный источник истины — строка ::error в логе самого changes; «Job 'changes' failed» у зависимых джобов и «'runs-on' key not defined» в act_runner v6.3.1 — шум. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 14:45:29 +05:00
bot-backend	507c8e0611	fix(tradein): неудача резолва yandex_jk_slug помечает дом — очередь не упирается в одни и те же пять (#2924) ... (полное описание — в PR) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 14:38:22 +05:00
bot-backend	6cdf56820d	fix(tradein): апсерт не переписывает неизменившуюся строку — гейт IS DISTINCT FROM + МСК-день (#2992) ... (полное описание — в PR) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:57:09 +05:00
bot-backend	865e64b783	feat(tradein/estimator): штраф за неизвестный год/тип дома — флагом, default OFF (#2936) ... В SQL-формуле relevance_score кандидат без year_built получает штраф 0 — столько же, сколько точное попадание в год, и лучше, чем кандидат с известным годом, отличающимся на 24 (2.0). То же с house_type. Отсутствие данных выигрывает у знания и возвышает источник с худшей полнотой. Флаг estimate_unknown_attr_penalty_enabled (default OFF): кандидат с NULL получает МЕДИАННЫЙ по пулу штраф того же признака среди тех, у кого он известен — не наказание и не награда; считается по тем же термам, что SQL (abs(Δyear)/12.0, 1.5 за несовпадение типа). Лежит в Python-слое после SQL, рядом с kitchen/ceiling (#2012), по тому же контракту: включать — только по бэктесту. Без чего флаг был бы мёртв (и был в первой редакции): _ANALOG_SELECT_COLS не выбирал year_built/house_type — SQL считал по ним CASE, но в словарь кандидата колонки не попадали, Python-слой видел None у ВСЕХ и не штрафовал никого по построению. Probe-лог в прод-оверлее: pool=30 null_year=30. Добавлены в _ANALOG_SELECT_COLS, во внешние SELECT тиров H/W и во внутренний base Tier W (он строится явным списком). Контроль: флаг OFF с колонками и без — метрики бэктеста идентичны до сотых. На этот инвариант стоит тест по исходнику запросов. Живой A/B (бэктест в прод-контейнере, оверлей /tmp/ab, 300 сделок ЕКБ Q2 2026, одна и та же выборка в обоих прогонах — проверено по deal_id): состав топ-50: сменилось 96 слотов из 5 915 (1.6 %), 27 сделок из 300 источники: avito 55.7→55.3 %, cian 24.5→24.8 %, yandex 12.7→12.6 % цена: MAPE 16.70→16.70, bias −4.52→−4.52, coverage 84.46→84.46 — идентично до сотых по всем срезам (сегменты, комнатность). Нижний Тагил (300 сделок, пулы 21/p90 40): 0 из 5 666 слотов сменилось. Почему эффект в разы меньше замера задачи (×0.20 avito): тот замер шёл по SQL тира H без стратификации. В боевом пути 54.9 % слотов топ-50 — гарантированная квота MIN_ANALOGS_PER_SOURCE=5, раздаётся ДО сортировки остатка; и у avito в топ-50 NULL-год лишь у 25.7 % (задача мерила 56 % по всем активным объявлениям). Обе величины измерены по фикстурам A/B. Что это значит: артефакт в формуле есть, флаг его корректно лечит, но на итоговую цену он не влияет измеримо. Включать по умолчанию оснований нет — и это и есть ответ, ради которого флаг заводился вместо правки. pytest tradein-mvp/backend: test_2936 7 passed; гейт фикстуры и roundtrip 8 passed; -k "estimat or analog" 735 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:27:18 +05:00
bot-backend	a003fdd37c	feat(tradein): ручка «дома, уехавшие от собственных объявлений» (#2996) ... Часть Находки 3 из #2996. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 05:54:33 +00:00
bot-backend	efc965a257	fix(db/ci): чистый старт БД больше не падает на 077 и не может уехать на пустой схеме ... Блокер переезда (#2990). Чистый старт на пустом томе падал: 077 читает foreign table gendesign_rosreestr_deals, а USER MAPPING создаёт бэкенд при старте (app/core/fdw.py), то есть ПОСЛЕ docker-entrypoint-initdb.d. Контейнер не поднимался вообще. Путь «пустой том» на реальном железе не исполнялся ни разу, а CI этот файл явно пропускал — гейт, который должен был поймать, был ослаблен. Проверено по всем 14 миграциям, упоминающим FDW-таблицы: читает ровно одна — 077. Остальные только CREATE/DROP FOREIGN TABLE и COMMENT, им ни USER MAPPING, ни связь с чужой БД не нужны. 077 не удалена, а сделана самозащитной: гард считает строки в md5-форме и выходит раньше обращения к FDW, если мигрировать нечего. На чистой БД таких строк нет по определению. Удаление файла было бы неверным — прод помнит миграции по bare-filename в _schema_migrations, и test_applied_migration_is_not_renamed_or_deleted падает на удалении. Исключение в ci-tradein.yml снято: теперь цепочка применяется целиком, то есть CI сам стал репетицией чистого старта. Отдельно закрыт тихий отказ в deploy-tradein.yml. Ветка baseline срабатывала по одному лишь отсутствию _schema_migrations, а это состояние неоднозначно: так выглядит и наполненный прод до внедрения tracking, и пустая БД нового сервера. Во втором случае baseline пометил бы все миграции применёнными, ни одной не прогнав, и деплой уехал бы зелёным на пустой схеме. Добавлен sentinel по listings: пусто → baseline пропускается, цепочка применяется с нуля. Refs #2990, #2989	2026-08-20 23:31:46 +03:00
bot-backend	fab0bc84c1	feat(tradein): ручка «дома, уехавшие от собственных объявлений» (#2996) ... Находка 3 задачи («23 дома лежат вне области 66, гарда на приёме нет») подтвердилась, и к ней добавились масштаб и причина. Масштаб: к этим домам привязано 591 объявление. Адреса екатеринбургские («Ул. 8 Марта», «Крауля», «Амундсена»), координаты — Варшава, Белград, Таллин, Владивосток, Ижевск. Причина: 22 из 23 несут в raw_payload след разового бэкфилла `full_backfill_2026-05-27`, который звал Yandex-геокодер напрямую, без резолва города. Живой путь при этом ЧИСТ — 0 записей вне региона в geocode_cache из 10 448 и 2 из 88 544 у listings; скрипта в репозитории нет. Это исторический осадок, а не текущая утечка, и гард нужен не столько живому пути, сколько следующему разовому скрипту. 17 из 22 помечены геокодером `precision: "exact"`. Точность отвечает на «нашёлся ли номер дома», а не «в том ли городе», и критерием приёмки быть не может — поэтому проверяется ПРИНАДЛЕЖНОСТЬ. Инвариант нарочно не географический: «дом рядом со своими объявлениями», а не «дом внутри рамки области». Рамка сломалась бы при выходе в Москву — ровно то, ради чего заведена #2996. Он же строго сильнее: ловит 25 домов против 23 у рамки, и оба лишних проверены («Ул. Белинского/Фурманова» за 207 км, 34 объявления). Порог 100 км не подобран на глаз. Замер по 9 052 домам: ближе 1 км — 8 914 (98.5 %), 25-100 км — 9 настоящих пригородов (Сарапулка, Кедровка, Чусовское Озеро, Ревда, Первоуральск; самый дальний 46.7 км), дальше 100 км — 25 (ближайший 119.2, максимум 5 079). Между 46.7 и 119.2 км нет НИ ОДНОГО дома: порог лежит в середине пустого промежутка. Первая редакция клала счётчик полем в /scraper/data-quality. Замер это остановил: запрос стоит ~445 мс на тёплом кэше, а обе существующие выборки той ручки вместе — 27 мс, при опросе фронтом каждые 120 с. То есть 17-кратное удорожание ради числа, которое меняется раз в месяцы. Проверка вынесена в отдельную ручку по требованию, и на возврат в горячий путь поставлен контроль-тест. Ручка отдаёт не только счётчик, но и масштаб (список домов + сколько объявлений привязано) — по одному числу «25» решение об очистке не принять. Двусторонне: против origin/main три теста красные, краснота везде по значению — ни одного ImportError/AttributeError. Контроль test_check_stays_out_of_the_polled_endpoint зелёный с обеих сторон. pytest tradein-mvp/backend — 4642 passed, 23 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 01:28:50 +05:00
bot-backend	b9cfdaa040	feat(tradein): secondary_only — параметр расписания, выброшенное считается (#1781) ... `run_cian_full_load` передавал `secondary_only=True` жёстко, поэтому включить новостройки в полный обход можно было только деплоем. Теперь это параметр с ТЕМ ЖЕ дефолтом `True` — поведение прода не меняется ни на строку, но решение становится правкой одной ячейки `scrape_schedules.default_params`, а не выкаткой кода. Откат — тем же движением. Почему это важно именно здесь. Новостройки НЕ пропускаются при запросе: они скачиваются, разбираются и выбрасываются последним шагом (`cian/serp.py`), потому что SERP-параметр `object_type=1` у Cian ненадёжен (~5 % выдачи) и фильтруют по authoritative `listing_segment` после парсинга. Проба бакета берёт `totalOffers` из Redux-состояния SERP и считает `pages_needed = ceil(totalOffers / offers_per_page)`, а `totalOffers` включает ОБЕ категории — то есть страницы с новостройками уже скачаны, лимит страниц и антибан-бюджет за них уже заплачены. Включение стоит ноль дополнительных запросов. Заодно `dropped_novostroyki` сохраняется в counters прогона. Счётчик логировался (`dropped_nb=`), но не персистился, и ответить «сколько инвентаря выбрасывает полный обход» задним числом было нечем: логи за 17.08 уже ротировались — `docker logs --since 120h` не находит ни строки «cian:» ни в одном контейнере. Тот же довод, по которому рядом заведён `partial_buckets`. Копится в атрибуте инстанса, а не аргументом `on_bucket`: у колбэка есть внешние реализации, менять его сигнатуру ради счётчика нельзя. Сброс на каждый прогон — инстанс переиспользуется. Замер, ради которого это делается (прод 21.08): месячный охват свипа cian/novostroyki — 11.7 % против 100 % у cian/vtorichka и avito/novostroyki; 11 993 активные строки, медианный возраст 81 сутки, 10 585 старше 30 суток. Подробности и оговорки — в #1781 и #2994. Двусторонне: против origin/main пять тестов красные, и краснота везде по значению, а не по отсутствию символа — ни одного KeyError. Сообщения перечисляют фактическое состояние («параметра нет в сигнатуре; параметры: [...]», «поля нет в запросе; поля: [...]»). Контроли зелёные с обеих сторон: дефолт остаётся True (иначе правка тихо включила бы сбор новостроек на проде — это отдельное решение с замером); фильтр при `secondary_only=True` остаётся на месте и по-прежнему зависит от флага. pytest tradein-mvp/backend — 4644 passed, 23 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 01:08:11 +05:00
bot-backend	28c374ab08	fix(tradein/search): снять STORED-generated с listings.tsv, не пересчитывать на каждом UPDATE ... listings.tsv (GENERATED ALWAYS ... STORED) пересчитывался на КАЖДОМ UPDATE listings независимо от того, менялись ли description/address, и заново перетостивался — ~5 ГБ TOAST-оборота за 91 день. Разведка: /api/v1/search (search_query.py) читает listings_search_mv, не listings напрямую, а витрина сама считает to_tsvector из сырых description/address/developer_name при каждом REFRESH — l.tsv она никогда не читала. DROP EXPRESSION безопасен для поиска и, по ATExecDropExpression (PG16), не вызывает table rewrite — catalog-only операция. listings_tsv_idx (GIN, 116 MB) снесён отдельно: 0 idx_scan за всю историю БД, не обслуживает ни один constraint. Колонка tsv остаётся (заморожена, без читателей) — DROP COLUMN вне рамок этой миграции. Refs #2992, #2989	2026-08-20 22:49:15 +03:00
bot-backend	3b40ba09f7	fix(tradein/geocoder): темп Nominatim сдерживается перед запросом, а не после успеха (#2953) (#2954)	2026-08-20 07:55:41 +00:00
bot-backend	a9e9707018	fix(tradein): обход Домклика начинается со сдвигом — комнатности 2+ перестают быть слепой зоной (#2854) (#2932)	2026-08-19 12:48:41 +00:00
bot-backend	cf48e6d6c8	feat(tradein): позиция квартиры внутри когорты аналогов — перцентиль (#2899) (#2926)	2026-08-19 10:08:18 +00:00
bot-backend	d0071c57bc	fix(tradein): фильтр выдачи Яндекса мёртв — slug ЖК ищем по странице объекта (#2860) (#2923)	2026-08-19 08:37:40 +00:00
lekss361	215b78a348	Merge pull request 'fix(tradein/estimate): залипший anchor_tier больше не глушит четыре механизма разом' (#2920) from fix/2656-anchor-tier-reset into main	2026-08-17 08:00:33 +00:00
bot-backend	42b0ebe338	fix(tradein/estimate): залипший anchor_tier молча глушил IMV-blend и quarter-index ... Флаг anchor_tier оставался равным anchor_tier_fetched ("A"/"C"), когда якорь фактически НЕ строился — сброс делал только low-conf гейт (#audit-1), но не Tier C corridor-гейт (#1795) и не сама _compute_same_building_anchor, когда она отклоняет кандидата (комплов меньше estimate_sb_min_comps). Дальше по коду залипший флаг читается как «headline построил якорь» и молча глушит IMV/Yandex blend (#651, гейт `anchor_tier is None`) и quarter-index correction (#764 Guard-1a) — притом что радиусный headline их не получал. Замер: 154 из 996 сделок теряют tier-флаг этой правкой, и у всех 154 изменение цены ровно 0.000% — чинится именно залипший ФЛАГ, не ценообразование (баланс метрик бэктеста подтверждает: единственная дельта в baseline — новая канарейка unrecorded_lookup_calls, все остальные метрики побитово те же). - estimator.py: сброс `anchor_tier = None` единой веткой `if anchor is None` после всех трёх гейтов (Tier C / low-conf / _compute_same_building_anchor); display-only IMV-карточка больше не гейтится по `anchor_tier is not None` (иначе терялась в щели «тир добыт, якорь не построен, headline подавлен»). - backtest_estimator.py: quarter_index_lookup/quarter_indexes_lookup в реплее отвечают «промах» (None/{}), если сброс флага открыл путь, которого не было в замороженной фикстуре, вместо падения с RuntimeError; счётчик таких промахов уходит в baseline как unrecorded_lookup_calls (точное целое, канарейка на расхождение реплея с захватом). Заодно пиннится estimate_dedup_analogs_enabled = False внутри replay_fixture (было только в самом гейте) — иначе штатная регенерация baseline (--from-fixture --update-baseline) писала baseline, который тест не совпадал бы никогда. - backtest_baseline.json: перегенерирован штатным путём, unrecorded_lookup_calls=0. Выделено из #2656/PR #2661 — фильтры свежести (scraped_at) в якоре дома и в знаменателе коэффициента выкупа остаются в исходном PR как отдельная, более спорная правка (двигает деньги: знаменатель просаживается на ~1.3% по бакетам).	2026-08-17 10:54:07 +03:00
bot-backend	c66047683c	Merge remote-tracking branch 'forgejo/main' into local/pr2836	2026-08-17 10:41:25 +03:00
bot-backend	73c4c487ed	fix(mera/b2c): житель Серова получал «вы вне области», а подсказки игнорировали выбранный город ... Два дефекта, найденных прогоном сценария глазами посетителя на живом домене. ## 1. Город предлагали выбрать, но отвечать по нему не умели Дропдаун на сайте (`OBLAST_CITIES`, city-registry.ts) и списки покрытия (`COVERAGE_GREEN/YELLOW_CITIES`, trade_in.py) — одно множество, записанное в двух местах. Они разошлись в обе стороны: предлагали, но не отвечали: Серов отвечали, но не предлагали: Берёзовский, Среднеуральск, Ревда Житель Серова выбирал СВОЙ город из НАШЕГО дропдауна и получал: «Этот адрес вне области, по которой мы собираем данные. Сейчас это Свердловская область: Екатеринбург целиком и ещё несколько городов вокруг.» Про город в той же самой области. Серов при этом покрыт данными: 363 активных объявления в радиусе 15 км, все свежие (замер по проде). Поэтому добавлен в жёлтый тир, а не убран из дропдаунa; три недостающих города добавлены на фронт. Шапка city-registry.ts этот риск прямо предсказывала — «перед добавлением 7-го города сверить оба списка вручную, теста на это пока нет». Теперь тест есть: бэкендовый сьют читает TS-реестр и требует РАВЕНСТВА множеств. Плюс проверка, что у каждого города с порогом есть центроид, — иначе порог мёртвый, город по координатам не резолвится. ## 2. Подсказки не слушались выбранного города `city_hint` доезжает до геокодера, но на выдачу не влияет: его смотрит только екатеринбургский кадастровый тир (как признак «речь не про ЕКБ, тир пропускаем»), а DaData-тир ограничен регионом целиком и хинта не принимает. Замер: выбран Серов, введено «Ленина 1» → первой подсказкой «Невьянский р-н, пгт Верх-Нейвинский». Человек выбирает верхний вариант и считает чужой дом — ровно баг #2576, ради которого город и спрашивают. Публичная ручка теперь подставляет город в саму строку запроса. Проверено на проде: «Серов Ленина 1» даёт серовскую выдачу целиком. Для Екатеринбурга подстановка безвредна — три разных адреса дали тот же результат с префиксом и без, поэтому правило одно на все города, без исключения для основного трафика. Чинится в публичной ручке, а не в геокодере: там от `city_hint` зависит поведение закрытого контура (`target_city_ambiguous`). ## Фикстура теста `_FAR_AWAY_CITY` стояла в 21 км от центра Серова и работала как «далеко от всех» лишь потому, что Серов не был поддержан. Переехала в Тавду — 271 км до ближайшего центроида. ## Мутации убрать Серов из покрытия (состояние прода) → падает сверка списков не подставлять город в строку → падает проверка ручки откат → 21 passed Плюс backend 75 passed, vitest 56 passed, tsc, lint, build, isolation guard. `city-registry.ts` добавлен в paths-фильтр БЭКЕНДОВОГО лэйна: сверку списков делает бэкендовый тест, и без этой строки правка одного лишь дропдауна её бы не запускала — то есть ровно тот путь, которым списки и разошлись.	2026-08-16 13:03:19 +03:00
bot-backend	56194c606a	fix(mera/b2c): семь дефектов публичного периметра, найденных состязательным ревью ... Ревью четырьмя независимыми линзами (периметр, семантика Caddy, политика ПДн против кода, фронт) + по два проверяющих на каждую находку. Ниже — то, что пережило проверку и воспроизведено на живом коде, а не выведено из чтения. ## Caddy: открытый редирект и потерянные ссылки Захват хвоста регекспом (`^/trade-in/mera-public/(.+)$` → `redir /{re…1}`) — открытый редирект. Захват берётся из РАСКОДИРОВАННОГО пути, поэтому `/trade-in/mera-public/%5Cevil.example/pay` даёт цель `/\evil.example/pay`, а браузеры трактуют `/\` как `//` — Location уводит на чужой хост. Готовая фишинговая заготовка с домена, который напечатан внутри оферты и уходит модератору эквайера. Заменено поимённым списком путей: такой адрес просто не матчится. Адреса со слэшем на конце (`/oferta/`, и длинные `…/oferta/`) отдавали 404 — ровно те ссылки, ради сохранности которых редирект и делался. Добавлена нормализация, цепочка замкнута (проверено: 2 перехода → 200). Query-строка терялась: размещённые ссылки с UTM приходили бы в аналитику как прямой заход. `uri strip_prefix` + `{uri}` переносит её. Обёртка `route` обязательна — без неё `redir` выполняется раньше `uri` и Location равен исходному адресу (бесконечный цикл, поймано на стенде). `/v3` — черновое превью с маркетинговыми плейсхолдерами — было открыто на боевом домене молча. Теперь названо вслух и запинено тестом. ## Гейты, которых не было `caddy validate` не звал НИ ОДИН workflow, а deploy применяет конфиг не через `reload` (тот отказался бы принять битый), а через `up -d --force-recreate` — опечатка уводит контейнер в crash-loop и роняет ВСЕ домены. Добавлен гейт в ci.yml, тем же образом caddy:2, что и на проде. Проверка «роут ↔ Caddy» была односторонней и пропускала обратную ошибку — путь, открытый наружу, о котором приложение не знает. Так и уехал `/v3`. Теперь двусторонняя, плюс проверка, что для каждой страницы есть 301. ## Бюджет внешнего геокодера Per-IP окна ограничивают одного клиента, но не сумму: 40/мин с адреса — это 57 600 в сутки при бесплатном тире DaData в 10 000, ОБЩЕМ с закрытым контуром. Подтверждено на проде: достаточно упомянуть не-екатеринбургский город, чтобы локальный тир отключился и запрос гарантированно ушёл во внешний сервис. То есть один скрипт оставлял без подсказок платящих пилотов. Per-IP снижен до 20/мин, добавлен общий суточный потолок 2000 и потолок одновременных подсказок (4): кадастровый тир уходит в FDW-скан чужой базы, держит соединение около секунды, а пул общий с B2B — полтора десятка параллельных публичных запросов клали бы закрытый контур. ## «Адрес нигде не сохраняется» — теперь правда целиком Две утечки, обе воспроизведены: 1. ЖУРНАЛЫ. Геокодер печатает введённую строку открытым текстом на каждый вызов, прод пишет stdout в persistent journald — адрес ложился на диск рядом с IP того же запроса в access-логе Caddy. Закрыто фильтром логов на время публичного запроса (contextvar, переживает await и to_thread). Закрытый контур логи сохраняет: они нужны для разбора жалоб пилотов. 2. МОНИТОРИНГ. sentry_sdk кладёт в событие ПОЛНОЕ тело запроса — а тело публичной ручки это ровно `{"q": "<адрес>"}`; `send_default_pii=False` тут не гейт, он про куки. Плюс брэдкрамб httpx несёт адрес в query геокодера. Закрыто `scrub_public_address`. Текст п. 5.4 политики расширен до «ни в журналы веб-сервера, ни в технические журналы, ни в мониторинг» — ровно то, что теперь обеспечено кодом. ## Фронт - Отмена запроса подсказок откладывалась внутрь следующего debounce-такта и не наступала вовсе, если человек переставал печатать: ответ по старой строке долетал и ложился в список. Контроллер создаётся сразу, отменяется в cleanup. - Список схлопывался на каждое нажатие — клик по намеченному пункту промахивался. Старая выдача висит, пока не пришла новая. - «Комнат» с лэндинга — свободный текст: «студия» не совпадала ни с одним option, селект показывал пустоту, parseInt давал NaN, на сервер уходил rooms: null → 422 с текстом «сломалось на нашей стороне». Нормализация вынесена чистой функцией и покрыта тестами. - У пробы покрытия не было ни таймаута, ни отмены: оборванное соединение оставляло кнопку в «Смотрим данные…» навсегда. 15 с + понятный текст. - Ошибка подсказок глушилась в пустой список — тупик без объяснения. - Комбобокс: Tab проваливался в кнопки подсказок, список не закрывался по уходу фокуса и перекрывал поля, Escape оставлял висячий aria-activedescendant. ## Проверено Локальный стенд (реальный site-блок Caddy + заглушка): 18 маршрутов, включая `%5C`, `//`, `%2F` — все три теперь 404. vitest 55 passed, backend 17 passed по публичному API, tsc, lint, build, isolation guard 41 файл, caddy validate. Мутации: снять редакцию логов → падает тест журналов; не вырезать тело запроса → падает тест мониторинга; убрать /estimate из Caddy → падает тест маршрутов.	2026-08-16 10:01:47 +03:00
bot-backend	b1fb7bb055	Merge remote-tracking branch 'forgejo/main' into feat/mera-public-api ... # Conflicts: # tradein-mvp/backend/app/core/rbac.py	2026-08-16 09:28:41 +03:00
bot-backend	7424c283d5	feat(mera/b2c): отдельный экран оценки на meraocenka.ru и короткие адреса ... ## Экран проверки — /estimate Проверка квартиры вынесена на собственный адрес: там у автокомплита есть место под список подсказок, а у результата — место рядом с полями. Форма в герое лэндинга осталась входной точкой и уводит сюда, донося набранное через sessionStorage (НЕ через query — адрес в URL попал бы в access-лог Caddy рядом с IP посетителя, а мы на той же странице обещаем ничего не хранить). Показывает живую пробу покрытия: сколько похожих квартир продаётся рядом и сколько в среднем висят их объявления. Ни одной рублёвой цифры — цену продаёт платный шаг. Тексты вердикта вынесены чистой функцией (coverage-copy.ts) и покрыты тестами: подпись под возрастом обязана говорить «объявление», а не «продаётся» (выборка цензурирована), при неизвестном возрасте плитки нет вообще, а пустая когорта объясняется как факт о рынке с подсказкой, что поменять, — директива «никогда не блокировать вывод». ## Короткие адреса Человек больше не видит /trade-in/mera-public/... — только /, /estimate, /oferta, /refund, /privacy. Длинные адреса отдают 301 на короткие: у страницы один канонический адрес, старые ссылки живы. Цена решения: ссылки работают только на meraocenka.ru (короткие пути раздаёт этот хост). Открывать лэндинг для проверки нужно там же, а не с gendsgn.ru. Ссылки эмитятся обычным <a> (PublicLink) — next/link подставляет basePath, и href="/estimate" уехал бы на несуществующий /trade-in/estimate. ## Три дефекта, найденных на живом сайте 1. Палитра v3 никуда не доезжала. b2c-tokens.ts не импортировал НИКТО, ни одна --b2c-* переменная не объявлялась, каскад молча пропускал такие декларации — лэндинг отдавал 200 бесцветным. Добавлен мост b2cVars, гейтом стал тест: каждая использованная в CSS переменная обязана быть объявлена. 2. Голый /trade-in/mera-public падал в 404 — матчер был со слэшем и звёздочкой. Ровно туда вела «Главная» в подвале. 3. «Для бизнеса» вела на «/» — то есть на сам лэндинг. Теперь абсолютный адрес B2B-контура. Пункты «Проверьте себя» и «Продажа под ключ» вели на якоря, которых нет нигде: приведены к виду «Статьи» — видны, но не кликабельны. ## Периметр и приватность Подсказки переведены на POST: access-лог публичного домена пишет URI целиком, то есть GET с ?q= сохранял бы адрес квартиры в файл. Тело в лог не попадает. Метод запинен тестом — это часть обещания, а не стиль. П. 5.4 политики ПДн переписан ВМЕСТЕ с кодом: прежний текст утверждал, что адрес не покидает браузер, и это перестало быть правдой. Новый говорит точно — передаётся, используется однократно, в базах не сохраняется. Последнее проверено по коду: suggest() работает без кэша, проба — один SELECT, аудит пишет строку только при наличии username. PUBLIC_ESTIMATE_ENABLED сузился до платного шага (бесплатная проба не хранит ничего, платный расчёт хранит). ## Проверено vitest 47 passed (9 файлов), tsc, next lint, next build, isolation guard 40 файлов, backend 75 passed, caddy validate = Valid configuration. Мутации структурных гейтов: убрать --b2c-accent-text из b2cVars → падает тест палитры убрать /estimate из @meraPages → падает тест маршрутов добавить импорт next/link → падает тест basePath откат → 14 passed Caddyfile добавлен в paths-filter фронтового лэйна: его читает тест маршрутов, и без этой строки правка одного лишь Caddyfile не запускала бы ни один гейт. Refs #2894, #2895	2026-08-16 09:27:04 +03:00
lekss361	a617ec7939	Merge pull request 'fix(tradein): гейт номеров миграций берёт эталон из git, ручной манифест удалён' (#2786) from fix/2683-manifest-drift into main	2026-08-15 20:04:16 +00:00
lekss361	22a1b3aff4	Merge pull request 'feat(tradein/ops): алерты GlitchTip доезжают в Telegram' (#2915) from feat/tradein-glitchtip-telegram-alerts into main	2026-08-15 19:56:40 +00:00
lekss361	58f04087bb	Merge pull request 'fix(tradein/payments): тело нотификации не течёт в мониторинг и аудит, повторы банка не отбиваются лимитом' (#2794) from feat/tradein-payments-perimeter-hardening into main	2026-08-15 19:48:18 +00:00
bot-backend	90133c4c2e	Слияние main в fix/2683-manifest-drift ... main принёс PR #2751 (ruff-шаг в ci-tradein.yml/backend-tests) параллельно с fetch-depth: 0 из этой ветки в том же job'е — не противоречат друг другу, слились автоматически. Единственное ручное разрешение — _manifest_applied.txt (modify/delete): main дописал файл, ветка его удаляет. Разрешение — удаление, это и есть предмет PR: гейт номеров миграций берёт эталон из git (origin/main), а не из ручного манифеста, который отставал и по построению не мог покраснеть (#2683, живой инцидент 15.08 — коллизия 264_ между двумя независимыми ветками).	2026-08-15 22:44:16 +03:00
bot-backend	b649caec2d	feat(tradein/ops): приёмник GlitchTip webhook-алертов в Telegram-тему ... Мониторинг GlitchTip сейчас нем (alerts_projectalert/alerts_alertrecipient пусты, EMAIL_URL=consolemail:// печатает письма в stdout, аудит на проде 2026-08-15). GlitchTip умеет получателя типа webhook, но шлёт свой Slack- совместимый JSON без каких-либо заголовков — Telegram Bot API его не понимает, нужен адаптер. - app/api/v1/glitchtip.py: POST /api/v1/trade-in/ops/glitchtip-webhook — принимает issue- и uptime-алерты (структурно одинаковый payload у GlitchTip 6.1.6, см. docstring), форматирует короткое сообщение (проект/заголовок/ссылка/время получения) и шлёт через существующий TelegramClient в отдельную тему алертов. Обрезка под лимит Telegram (4096 симв.), неизвестная форма payload пересылается как есть с пометкой вместо 500. - Auth: GlitchTip не может слать кастомные заголовки (aiohttp.post без headers=) — переиспользуем TRADEIN_INTERNAL_AUTH_SECRET (#2213) как query-параметр `secret`, constant-time compare. В отличие от rbac.py пустой секрет здесь fail-CLOSED (503), это единственный auth-рубеж пути. - config.py: TELEGRAM_ALERTS_CHAT_ID / TELEGRAM_ALERTS_TOPIC_ID — намеренно отдельные от TELEGRAM_SUPPORT_*, чтобы алерты не лились в топик клиентов. - rbac.py: путь добавлен в _PUBLIC_PATHS (фиксированный, без секрета в самом пути — секрет только в query). - docker-compose.prod.yml: glitchtip-worker (реально шлёт вебхуки, не glitchtip-web) переведён на networks: [default, shared] — без этого tradein-backend не резолвится с его стороны (общей сети не было вообще).	2026-08-15 22:39:44 +03:00
lekss361	48e75534bb	Merge pull request 'chore(ci): деплой на изменение ролей, ruff-гейт для МЕРЫ, удаление мёртвого workflow' (#2751) from chore/ci-config-cleanup-v2 into main	2026-08-15 19:39:05 +00:00
bot-backend	d046eaada2	feat(mera/b2c): публичный API МЕРЫ — /api/public/mera/{suggest,coverage} ... Первый шаг к отдельному B2C-интерфейсу оценки на meraocenka.ru: домен получает собственную поверхность бэкенда вместо того, чтобы тянуть куски закрытого контура. ## Отдельный префикс, а не проброс кусков /api/v1/* На meraocenka.ru действует allowlist-by-default. Открыть там API можно было двумя способами: перечислить нужные v1-пути поимённо — или завести префикс, под которым по определению не лежит ничего закрытого. Выбран второй: при первом одна опечатка в матчере (`/trade-in/api/*` вместо точного пути) открывает наружу весь v1 — ~20 ручек, включая PDF расчётов, фотографии и админку. Цена ошибки, а не удобство. Добавить сюда приватную ручку теперь нужно СПЕЦИАЛЬНО — положив файл в app/api/public/. Случайно нельзя. ## Ноль записей в БД Обе ручки только читают: /coverage — один SELECT, /suggest — прокси автокомплита. Это условие, при котором публичная форма работает ДО контура согласия 152-ФЗ (#2895: сегодня адрес физлица попадает в trade_in_estimates раньше согласия, а пути удаления в бэкенде нет). Платный расчёт, который писать будет, открывается только вместе с ним. ## Делегирование, а не копии Обе ручки вызывают те же функции, что обслуживают закрытый контур (v1.geocode.suggest_addresses, v1.trade_in.coverage_probe). Разбор #2894 показал, чем кончается вторая копия когорты: проба отвечает «данные есть» там, где платный расчёт видит ноль. Публичный ответ переиспользует CoverageProbeResponse — на нём уже стоит гейт «ни одного price-подобного поля». ## Бюджеты Общего 300/60с мало: /suggest через DaData-тир — платный внешний вызов, абуз стоит денег. Свои per-IP окна: 40/мин на подсказки (человек с debounce'ом тратит единицы на адрес), 15/мин на пробу. ## Проверено 11 тестов, из них структурные: набор ручек под /api/public проверяется на РАВЕНСТВО (третья, добавленная без правки теста, роняет сборку) и сверяется с rbac._PUBLIC_PATHS в обе стороны — чтобы не осталось открытого пути-призрака. Рядом висит закрытый маршрут-двойник: без него «аноним получает 200» одинаково зелёный и когда исключение точечное, и когда auth-гейт снят целиком. Мутации: убрать пути из rbac._PUBLIC_PATHS → 7 failed / 4 passed снять бюджет с /coverage → 2 failed / 9 passed откат → 11 passed Плюс 72 passed на связке rbac + coverage + version, `caddy validate` = Valid configuration, ruff чист. Смоук периметра дополнен парой, которую нельзя разделять: публичные ручки отвечают 200 анонимно И /trade-in/api/v1/* на этом домене по-прежнему 404. Зелёная только первая проверка = API открыт целиком, а тест этого не заметил. Refs #2894, #2895	2026-08-15 22:32:53 +03:00
bot-backend	a8fa7364ae	merge(tradein/payments): влить main в feat/tradein-payments-perimeter-hardening ... Слияние main принесло собственные Sentry-скрубберы (redact_telegram_bot_token + stabilize_retry_error_fingerprint) в app/main.py и app/scheduler_main.py — конфликт разрешён композицией, а не выбором стороны: обработчик перед отправкой в GlitchTip теперь прогоняет событие через всю цепочку в указанном порядке: scrub_payment_request_body → scrub_pii_event → redact_telegram_bot_token → stabilize_retry_error_fingerprint (main.py), и без redact_telegram_bot_token в scheduler_main.py (тот процесс не держит TelegramClient) — оба канала, before_send и before_send_transaction, используют один и тот же обработчик. tests/test_sentry_scrub.py: тесты обеих сторон объединены без потерь — PR-D2 платёжный composed-тест (body-wipe + PII-scrub + token-redaction) и весь блок RetryError fingerprint-стабилизации из main сосуществуют в одном файле.	2026-08-15 22:32:28 +03:00
bot-backend	87258075a2	Merge main в chore/ci-config-cleanup-v2 ... Слить актуальный main (билд-раннер #2841/#2869, невалидные индексы #2752, честный health-check и deploy-status #2841) в ветку очистки CI. Один конфликт в .forgejo/workflows/deploy.yml: список triggers.paths — main добавил ops/docker-prune.sh (#2887), ветка добавила auth/** (RBAC roles config). Разрешено сохранением обоих путей, без потери ни одного триггера.	2026-08-15 22:30:47 +03:00
bot-backend	aee0d36e7a	fix(tradein/scraper): listing_segment самочинится при upsert вместо вечного NULL ... Раньше listing_segment писался ТОЛЬКО при INSERT в save_listings — строка, единожды родившаяся с NULL-сегментом (классификатор не сработал на первом скрейпе), никогда не получала сегмент на повторных сборах, даже когда он становился определим. Симптом лечила отдельная джоба деактивации (deactivate_stale_{cian,yandex}_null_segment, миграция 266, PR #2908) — чистит мусор, но не саму запись. Добавлен listing_segment = COALESCE(EXCLUDED.listing_segment, listings.listing_segment) в ON CONFLICT DO UPDATE, и тот же идиом в reconcile-UPDATE (dedup_hash-drift fallback path) — иначе self-heal был бы неполным для строк, прошедших через этот путь. COALESCE, а не голый EXCLUDED, чтобы повторный скрейп без определённого сегмента не затирал уже известное значение пустым (тот же паттерн, что уже применён для city/kitchen/ceiling). Тесты: tests/test_listing_segment_upsert_selfheal.py — INSERT-путь, ON CONFLICT COALESCE (обе стороны), reconcile-UPDATE COALESCE.	2026-08-15 22:28:05 +03:00
lekss361	12007f8615	feat(tradein): бесплатная проба покрытия POST /coverage (#2894) (#2909)	2026-08-15 18:28:08 +00:00
bot-backend	37e738c802	fix(tradein/coverage): resolve city by coordinates, not sweep-context city_hint ... Повторная проверка /coverage закрыла оба MAJOR из #2894, но выявила три новых дефекта: 1. Город больше не резолвится из моды listings.city найденной когорты — эта колонка хранит город SWEEP-контекста скрейпера (миграция 196), не геокод адреса объявления. Замер на проде: 90/90 строк в радиусе 1000м вокруг Берёзовского имеют city='Екатеринбург', 74/74 вокруг Ревды — city='Первоуральск'. Города-спутники из COVERAGE_GREEN/YELLOW_CITIES были физически недостижимы. Город теперь резолвится детерминированно по lat/lon запроса — ближайший центроид из статичной константы (8 городов, рядом с ручкой, не в БД — comment объясняет почему) в пределах 25 км. city_hint остаётся в схеме (фронт его шлёт для соседних ручек), но чисто информационный — на порог/статус не влияет. 2. test_max_age_outlier_days_passed_to_sql проверял подстроку, которая встречается в SQL дважды (count и percentile_cont) — мутация «убрать FILTER у percentile_cont, оставив у count» проходила зелёной. Добавлен живой поведенческий тест (вставляет когорту + выброс days_on_market=4000, проверяет что медиана не сдвигается) — ловит эту мутацию (подтверждено: median 8→9 при мутации). 3. _live_session() вызывался в pytest.mark.skipif на этапе сбора тестов и создавал никогда не закрываемый Session, плюс дублировался в теле теста. Заменено на _live_db_available() (open+close голого connection) для skipif и pytest-фикстуру live_session с гарантированным close/dispose. 4. Nit: пустая когорта в поддерживаемом городе отдавала status=not_covered вместе с ненулевым threshold — противоречило докстрингу CoverageProbeResponse.threshold ("0, когда порог неприменим"). threshold теперь всегда 0 при not_covered, независимо от причины.	2026-08-15 21:20:43 +03:00
bot-backend	e00dcac177	fix(tradein/deactivate): resolve migration 264 renumber collision on merge with main ... fix/tradein-ttl-effective-cap (PR #2907, merged into main while this branch was in flight) already claimed 264/265 for deactivate_stale_avito_cap_mult / deactivate_stale_yandex_cap_mult. Renumbers this branch's 264_seed_deactivate_stale_null_segment_yandex_cian.sql -> 266_seed_... (git mv + _manifest_applied.txt entry moved after 264/265 + self-references in the migration header and in test_deactivate_stale_listings.py's _MIGRATION_264 constant/test names). Merges main's bool-guard (ttl_days/cap_mult reject bool) + CAP_MULT ceiling + per-source cap_mult calibration with this branch's null_segment_only kwarg (explicit `listing_segment IS NULL` predicate, since ANY(:segments) never matches NULL) -- both features apply to the same deactivate_stale_listings() call site in product_handlers.py and the same function signature/docstring in deactivate_stale_avito.py, so every conflict was signature/docstring-level, not logic-level (git already auto-merged the function body correctly since the two features touch disjoint lines below the signature). Also reconciled the module docstring's "known gap" note (main) to reflect that the NULL-segment slice it measured (cian 211 / yandex 523 rows >60d) is now closed by this migration -- novostroyki stays open, unrelated to this branch.	2026-08-15 21:13:41 +03:00
bot-backend	08cff706ec	docs(tradein/deactivate): убрать неверное число из обоснования потолка ... В шапке модуля, в комментарии миграции 264 и в докстринге теста стояло «23 687 из 44 744 avito-объявлений не подтверждались >7 суток» под заголовком «ЗАМЕР НА ПРОДЕ». Число реальное, но приписано не тому. Перепроверено запросом 2026-08-15: это ВСЕ источники вместе, и две трети — новостройки, которых оценщик не берёт (он фильтрует listing_segment IS NULL OR = 'vtorichka'). У самого avito просроченных строк ноль: 8 663 активных, максимальный возраст 10 суток. Оставлять это в коде нельзя: следующий человек прочитает «avito раздут вдвое», проверит и не найдёт — а заодно потеряет доверие к остальным числам в том же абзаце, которые верны и сверены с scrape_runs.counters. Заодно явно записано, чего потолок НЕ делает: он не сжимает пул (0 деактиваций замерено на всех четырёх джобах), а защищает от разгона пола и от опечатки в расписании. Настоящий раздутый срез — строки с пустым сегментом, они чинятся отдельной джобой.	2026-08-15 21:00:42 +03:00
bot-backend	3e9af2fdef	fix(tradein/coverage): sync cohort with paid estimator, honest age medians ... Independent review found two MAJOR defects in POST /api/v1/trade-in/coverage: MAJOR-1: the probe cohort WHERE clause was missing three predicates present in estimator._COMMON_WHERE / Tier W (novostroyki guard, geo_precision != 'city', price_rub > 0) — the free probe could answer "ok" at points where the paid estimator's own 1000m radius tier sees zero real analogs. Prod example: 56.868904/60.837955, 2 rooms, 50 m2 gave n_listings=22/status=ok while the estimator's cohort at the same radius was 0 (all 54 rows were novostroyki). Added the three predicates verbatim from estimator.py, plus both a static SQL-text regression test and a real-Postgres integration test (skip_allowlist.txt, same _live_session() pattern as test_gar_flats_loader) that inserts novostroyka/geo_precision=city/price=0 rows and asserts they are not counted. MAJOR-2: median_listing_age_days was computed from days_on_market, which on prod is populated almost exclusively by one source (yandex) — thin cohorts produced a "median" over 1-2 listings. Added n_with_age to the response (honest count of listings the median is based on); median is now null below COVERAGE_MIN_AGE_SAMPLES=5, and values above COVERAGE_MAX_AGE_DAYS=365 (near -certainly dead listings, per prod: 15% of fresh yandex rows exceed 365d, max 4261d) are excluded as outliers before the percentile is computed. MINOR: city_hint was trusted at face value and echoed back verbatim — a client could pass city_hint="Екатеринбург" with coordinates in Серов and get threshold=8/status=ok. _resolve_coverage_city now prioritizes the SQL cohort's mode city (ground truth) over the client hint, falling back to hint only when the cohort is empty (where status is forced not_covered anyway). Unmatched cities no longer echo the raw client string in the city field.	2026-08-15 20:47:23 +03:00
bot-backend	cfb4c159ab	fix(tradein/scraper): deactivate stale yandex/cian listings with NULL segment ... 544 yandex + 224 cian active rows carry listing_segment=NULL (legacy rows predating migration 011, plus a small trickle that can never self-heal since the upsert ON CONFLICT never rewrites listing_segment on re-scrape). 94-97% of them are frozen at ~86 days old, yet the estimator's Tier A (same-building) and Tier C (micro-radius) anchor queries filter only is_active=true -- no freshness column -- so these stale asking prices anchor live valuations. deactivate_stale_yandex/_cian (migration 115) already run at TTL=30 but scope segments=['vtorichka'] only: `= ANY(CAST(:segments AS text[]))` never matches NULL, so the NULL bucket was invisible to both existing jobs and to avito/domklik/n1 (which are source-blanket or vtorichka-only respectively). Adds null_segment_only kwarg to deactivate_stale_listings() building an explicit `listing_segment IS NULL` predicate (confirmations/revisit-floor builders extended in parallel for correctness, though both gates are kept off for this slice -- population too small for thresholds calibrated on a full vtorichka sweep, would permanently skip as unhealthy). Two new scrape_schedules rows (migration 264) run it per source, untouched novostroyki/vtorichka jobs unaffected. TTL=60d (vs 30d for vtorichka): revisit-floor is not computable here (rows out of dedicated sweep scope have no revisit-gap history), so the margin is folded into the TTL directly -- 2.26x/1.4x over the measured p99 revisit gaps already on file for cian/yandex vtorichka (26.6d/43.0d). Bimodal age distribution means this costs almost nothing in coverage (30d vs 60d: 744 vs 734 deactivated). First run: 734 of 768 NULL rows deactivated (211 cian, 523 yandex), 34 remain (fresher than 60d, still incidentally re-touched). Comparable pool (is_active AND segment IN (NULL, vtorichka)) after: cian -2.7% (7739->7528), yandex -10.2% (5133->4610) -- yandex crosses the 10% flag threshold. All 734 removed rows already had scraped_at frozen >60d, i.e. already excluded from Tier S/H (which do filter freshness, 14-60d window) -- the drop is real for is_active headcount but zero-impact there; it only prunes Tier A/C, where it removes stale prices rather than live comps. Separate finding (not fixed here): base.py's ON CONFLICT DO UPDATE omits listing_segment from SET entirely, so a legacy NULL row can never heal even though cian/yandex SERP always compute segment deterministically on re-scrape.	2026-08-15 20:44:36 +03:00
bot-backend	19c9da8119	fix(tradein/deactivate): bool guard hole + unpinned test + yandex cap_mult gap (TTL-CAP round 3) ... Три остатка ревью TTL-CAP: 1. cap_mult < 1 пропускал bool: jsonb true -> True < 1 ложно -> потолок = ttl_days*True = ttl_days -> пол молча отключается без ValueError. Тот же класс дыры возможен и через ttl_days=true (TTL молча = 1). Оба параметра теперь явно отклоняют bool ДО числового сравнения; воспроизведено на HEAD и закрыто тестами (True/False на обоих параметрах). 2. test_avito_prod_floor_is_capped_by_calibrated_cap_mult хардкодил cap_mult=6 как вход -- мутация миграции 264 (6 -> 2) оставляла набор зелёным. Тест теперь читает cap_mult ИЗ ФАЙЛА миграции regex'ом, ожидаемый результат (потолок 60) остаётся зафиксированным числом -- дрейф калибровки в SQL теперь ломает тест. 3. Текст миграции 264 утверждал "yandex 43.0 -> потолок 60, запас есть" по статическому p99. Живые полы из scrape_runs.counters (08-10..08-15: 75/75/75/39/52/54) и live-замер сегодня (79.2, n=1961) выше потолка 60 -- тот же false-kill класс, что у avito. Откалибровал yandex отдельной миграцией 265 (cap_mult=3 -> потолок 90, тот же запас ~14%, что у avito), поправил таблицу в 264 на живые числа и пиннящий тест по образцу avito. Численный эффект (live-замер 2026-08-15, до и после): next-run deactivated=0 на всех четырёх джобах что до, что после -- ветка по-прежнему НЕ сжимает пул (avito/cian: живой пол уже ниже потолка, cap не участвует; yandex: 0 активных строк старше 39 суток вообще, калибровка убирает будущий риск, не текущее число; domklik: блокирован гейтом здоровья, confirmations 94 < 200). Ветка остаётся тем, чем и была: защита от опечатки в расписании + калибровка, не сжатие пула. 4508 backend-тестов зелёные (uv run pytest tests/), ruff чист на изменённых файлах.	2026-08-15 20:42:00 +03:00
bot-backend	8fff174337	Merge remote-tracking branch 'forgejo/main' into fix/tradein-ttl-effective-cap	2026-08-15 20:26:40 +03:00
bot-backend	d0105470f4	feat(tradein/coverage): бесплатная проба покрытия для лендинга МЕРА (#2894) ... POST /api/v1/trade-in/coverage — до оплаты пользователь видит только n похожих объявлений в радиусе 1000м и медианный возраст листинга, без единой цены. Один SQL (радиус GIST + rooms + area ±15% + freshness 14д + тот же дедуп/cap- канон, что у estimator._fetch_analogs), ноль внешних вызовов, ноль записей. Пороги ok/thin/not_covered — константы рядом с ручкой (зелёные города >=8, жёлтые >=12, остальные всегда not_covered). Поле median_listing_age_days (не "срок продажи" — возраст активного объявления, цензурированная выборка). RBAC не тронут — путь остаётся закрытым, открытие анонимного периметра вынесено в #2895.	2026-08-15 20:16:11 +03:00