Этаж — обязательное поле карточки: без него форма не отправляется. При этом
saveDraft его не клал, а на целевой странице поля этажа нет вовсе. Комментарий
объяснял это тем, что «повторно набирать одно короткое поле дешевле, чем
хранить лишнее» — довод неверен: переспросить негде, и обязательное поле
работало чистой помехой.
Схема бэкенда этаж принимает (TradeInEstimateInput.floor), и на цену он влияет
(первый и последний этаж). Хранится теперь по тому же доводу, что и состояние:
выбросить уже полученный ответ и спросить второй раз хуже, чем донести.
Тест — через САМУ ФОРМУ, и это не формальность. Первая попытка защитить правку
звала saveDraft({floor}) напрямую: она проверяла round-trip хранилища и
оставалась зелёной, когда из FreeCheckCard убирали передачу этажа, то есть
ровно при возврате чинимого дефекта. Сторож, который не сторожит. Теперь форма
заполняется и отправляется целиком; снятие проводки даёт «expected undefined to
be 7/16» — красное по значению.
Плюс три случая на само хранилище: старый черновик без поля переживает выкатку,
нестроковое значение выпадает не унося остальное.
Прод отдавал «г Екатеринбург, ул Фролова , д. 29, корп.»: реестровый
readable_address (ЕГРН) приходит УЖЕ склеенным вместе с пустыми частями —
маркер без значения печатается, лишний пробел перед запятой остаётся, и все
тиры /suggest (cadastral / geoportal / houses / DaData / Nominatim) пропускали
строку насквозь.
Чиним склейку, а не конкретный случай: `tidy_address()` — один проход по
частям (схлопнуть пробелы, выбросить пустые и маркер-без-номера:
корп./стр./лит./кв./оф./пом. и пр.), склейка обратно. Применяется в
`GeocodeSuggestion.__post_init__` — единственной точке, через которую проходят
все тиры, включая локальные, которые питают и `geocode()`.
Тест на функцию склейки, фальсифицирован снятием фильтра пустых: краснеет по
значению строки (10 из 14), а не исключением.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
axe 30.08 нашёл 32 узла color-contrast (все serious). Причина одна на все:
пары «цвет × фон» подбирались глазами, а числа в комментариях писались по
памяти — шапка b2c-tokens.ts утверждала «onAccent на accentDeep 4.6:1», тогда
как реальный замер 4.41, то есть главная кнопка призыва не проходила норму, а
документация уверяла, что проходит.
Затемнены четыре токена до запаса на худшем светлом фоне (surfaceSoft, он
темнее pageBg): accentDeep 4.41→4.97, muted 4.45→5.36, success 4.04→4.96,
danger 4.60→5.23. Оттенок сохранён, фирменный вид не меняется.
Отдельный класс — светлый токен на тёмной плашке surfaceDark, где шкала
перевёрнута: метки тикера красились muted (2.7) и accentText (2.85), стрелка
между прогнозом и фактом — линейным #2c3a3f (1.50). Переведены на mutedDark
(6.2) и accent (6.24). Заодно убраны сырые hex #9fb0b4 (2.24 на светлом —
.artSoon, .gameScale, .repPaidFine, .artFootnote; 7.84 на тёмном) — палитра
запрещает hex в CSS именно потому, что мимо токена величина не считается
никаким аудитом.
Регресс ловится без браузера: contrast-tokens.test.ts считает яркость по
формуле WCAG прямо на значениях токенов и проверяет ОБА фона страницы, плюс
сторож на новые сырые hex в CSS. Проверен фальсификацией: возврат muted к
#667579 красит тест.
Над лентой стояло «медианное расхождение с ценой ДКП — 14,5 % по 327
сделкам», а в самой ленте 5 строк из 20 расходились больше чем на 30 %
(75,7 · 63,6 · 47,4 · 41,4 · 38,5). Первое, что видел посетитель страницы
про точность, — крупный промах без единой цифры контекста.
Промахи не прячутся: строки витрины отобраны по ПОЛНОТЕ и СВЕЖЕСТИ
(_sort_key в app/tasks/landing_showcase_deals.py), отбор по величине
ошибки был дефектом и снят. Лечится контекстом — под лентой печатается
тот же разброс ПОКАЗАННЫХ строк, что уже стоит под таблицей сверок:
медиана модуля и худшая, обе из shownSpread() (deal-view.ts), второго
расчёта не заводится. Вывода вида «зато обычно точно» в подписи нет: он
протух бы на первом пересчёте витрины, а два числа рядом — нет.
Разметка: бегущая часть выделена в .tickerStrip — position/overflow
нужны только ей, иначе абсолютный бейдж растянулся бы и на подпись.
Проверка (landing-v3-render.test.tsx): те же строки с худшей и без неё
дают РАЗНЫЕ числа в подписи — она сосчитана по показанному, а не вписана.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
«Симуляция пробы покрытия на боевой базе (poincare, 30.08.2026)» доезжала до
экрана: CITY_COVERAGE_SOURCE собирается в coverage-copy.ts и рендерится в
EstimateFlow.tsx:323. На первом экране лендинга строки не видно — она
появляется в форме проверки, после выбора города, поэтому grep по
отрендеренной главной давал ноль и дефект выглядел несуществующим.
Хостнейм посетителю не сообщает ничего: «на боевой базе» несёт весь смысл.
Убран из обеих строк-источников (сверка бэктеста и проба покрытия) и из
комментария в статьях.
Гейт смотрит в ИСХОДНИК, а не в вывод: какой путь рендера показывает строку
сегодня, знать не нужно — завтра он будет другим. Список запретов явный, без
эвристики «похоже на хостнейм»: она ловила бы domclick.ru и avito.ru в текстах
про источники данных. gendsgn.ru в список НЕ входит — это публичный домен B2B,
на который лендинг ссылается кнопкой «Для бизнеса».
Гейт проверен фальсификацией: возврат хостнейма даёт красное с указанием
landing-facts.ts:207, а не пустой список.
Тест занимал все слоты семафора четырьмя висящими запросами и ждал, что
они дошли до acquire, обычным сном на 50 мс. На нагруженном раннере этого
не хватало: пятый запрос заставал свободный слот, входил в подменённую
оценку и вставал на gate.wait() — а gate.set() стоит ниже по тому же
корутину. Дедлок до pytest-timeout, две минуты простоя job'а и красный CI
на постороннем PR (#3268).
Сон заменён счётным барьером: подменённая оценка отпускает семафор при
входе, тест дожидается ровно _CONCURRENCY входов. Вход означает, что слот
уже захвачен, — это то самое условие, которое сон угадывал по времени.
Проверено пробой с намеренно свободным слотом (держателей на одного
меньше): старая структура висит до таймаута, новая падает за 12с с
понятным сообщением.
Посетитель видел 20 строк сверки и не мог понять, где они лежат
относительно выборки: первой в таблице стоит сделка с расхождением
+75,7 %, а медиана по всем 327 — 14,5 %. Порядок строк при этом верный
и менять его нельзя — отбор идёт по полноте и свежести, а не по
величине ошибки (отбор по ошибке был дефектом и уже убран).
Поэтому не переупорядочиваем, а добавляем контекст: медиана модуля
расхождения показанных строк, сколько из них в пределах порога и
худшая — рядом с медианой всей сверки. Замер на проде 30.08.2026:
показанные 11,5 % против 14,5 % по всей выборке, 12 из 20 в пределах
20 %, худшая 75,7 %.
Считается на фронте из тех же объектов, которые рисует таблица, —
второе место подсчёта рано или поздно отстало бы от строк на экране.
Своей формулировки «чуть точнее» в подписи нет: она протухнет на
первом же пересчёте витрины, а два числа рядом не протухают.
Порог вынесен в WITHIN_PCT рядом с фильтром: гейт витринных чисел
справедливо покраснел на вписанных руками «20 %» при <= 20 в коде.
_extract_json искал маркеры блока подстрокой по ВСЕМУ телу ответа — до
разбора JSON, то есть и по пользовательским описаниям объявлений.
Прод 30.08, прогон 5363: продавец написал в описании квартиры «🔹 Система
защиты от протечек». Подстрока совпала с маркером «система защиты», ответ
на 107 183 байта с двадцатью валидными офферами был объявлен блок-
страницей, свип оборвал все комнатные корзины и забанил живой узел пула
на 6 часов. Совпасть так же могут «captcha» и «qrator» — в тексте
объявления, в имени агентства, в ссылке.
Порядок перевёрнут: сначала разбор JSON, маркеры — только если разбор не
удался. Разобранный JSON нужной формы блок-страницей быть не может,
QRATOR отдаёт HTML, так что валидный разбор сам по себе доказывает
отсутствие блока. Тот же порядок давно применён в detail.py — там
маркеры смотрят только когда __SSR_STATE__ не найден; свип был
единственным местом с обратной логикой.
Мусор без маркеров теперь ValueError, а не блок: за неразобранный ответ
неизвестной природы узел банить нельзя.
Тест проверен мутацией: со старым порядком 8 проверок из 11 краснеют,
включая дословный фрагмент описания из прогона 5363.
Пройденный QRATOR proof-of-work выбрасывался после каждой карточки: `reuse_context`
во всём репозитории передавал ЕДИНСТВЕННЫЙ вызов — domclick_detail_backfill.py:346.
Значит каждый /fetch Авито шёл через sidecar'овский browser.new_page(), то есть
новый изолированный context с пустой банкой кук. В логе прод-сайдкара это видно
прямо: «PoW-челлендж снят за ~1000мс» печатается на КАЖДОЙ успешной карточке —
челлендж решается заново каждый раз, а не один раз на прогон.
Эффект той же правки у Домклика измерен и записан в domclick_detail_backfill.py:331
— 26 последовательных фетчей сайдкара дали 100% блоков, те же карточки в тёплом
контексте 5/5 за ~2с.
Второй холод — сам заход: providers/avito/detail.py звал fetch(full_url) голым,
без origin и без Referer, тогда как Домклик (#3247) идёт fetch(card_url,
origin=SERP, referer=origin). Существующий для Авито прогрев (warm_up_session)
живёт только в curl-пути и с 22.08 в проде мёртв — AVITO_DETAIL_BACKFILL_USE_CURL
выставлен в false.
Что сделано:
- avito_detail_backfill: reuse_context=True + request_context_reset() РОВНО один
раз за прогон и только на AvitoBlockedError. Не на AvitoSidecarUnavailableError
(подтип AvitoRateLimitedError — отказ нашего тракта, не бан площадки) и не на
AvitoListingGoneError. Зеркалит #3212: сброс на каждый блок сам себя
поддерживает — пропуск живёт в context'е, сброс его выбрасывает, повторная
проверка с того же IP снова блокируется, одна осечка даёт каскад.
- fetch_detail: необязательные origin/browser_referer (имя referer уже занято под
Referer curl-пути, это разные фетчеры и разные поля). Дефолт None → payload и
поведение city_sweep/pipeline/admin не меняются.
- _serp_origin_for: городская SERP из URL карточки, хост берётся из самого url.
Попутно — дефект якорной вкладки сайдкара, найденный при переносе. _ensure_anchor_page
отдавала True на ЛЮБУЮ живую вкладку, не сверяя её с запрошенным origin. А origin у
обоих caller'ов выводится ИЗ URL карточки и меняется вместе с городом (Авито —
сегмент пути, Домклик — поддомен). После первой же карточки другого города Referer
называл выдачу, которую этот контекст никогда не открывал: ни куки её, ни тайминга,
площадка видит заявленный переход без единого следа. Ровно то, что #3258 запретил
делать фолбэкам якорного поиска. Добавлен _anchor_origins: origin сменился — вкладка
переоткрывается. Чинит и Домклик тоже.
Заход через поиск Яндекса (BROWSER_ANCHOR_VIA_SEARCH) для Авито НЕ включается —
расширять этот список без отдельного замера запрещает комментарий у самой константы.
Хранилище авторизованных сессий Авито (#3179/#3180) этой правкой не заменяется.
База для сравнения снята ДО выката и записана в #3251: доля блоков от попыток
46.9% / 74.2% / 96.4% / 69.8% / 52.9% / 62.3% по суткам 25-30.08. Сравнивать после
деплоя по доле блоков и обогащению за сутки, а НЕ по статусу прогона: ratio-критерий
обрывает КАЖДЫЙ прогон, и статус banned про площадку ничего не говорит.
Тесты: backend 5150 passed / 37 skipped, сайдкар 211 passed (было 206 + 5 новых на
переезд якоря), ruff чист.
Refs #3251, #3180, #3118, #3212, #3247, #3258
BFF-ручка Домклика не страница, а JSON-эндпоинт SPA. Сайдкар умел ровно
одно — page.goto(url), — и навигацией браузера на API-хост мы делали то,
чего настоящий клиент не делает никогда. Перехват сети на живой выдаче
30.08 это и показал: офферы приезжают в SSR-документе, а к BFF ходят
XHR'ы за гео, районами и метро.
Через мобильные узлы пула такая навигация упиралась в ChallengeTimeout:
прогоны 5330 и 5351 — 9 из 9 и 6 из 6 запросов зависли на челлендже, 0
лотов. Карточки через те же узлы в те же минуты шли.
Замер трёх режимов на одном узле, один и тот же ресурс:
BFF navigate ChallengeTimeout, 55с
BFF subresource HTTP 200, 52 байта, 6с
BFF page_fetch ошибка
Подзапрос проверен вширь: все шесть комнатных корзин HTTP 200, суммарно
6359 офферов против 6367, снятых напрямую с резидентного IP (расхождение
— дрейф фонда за пару часов); список офферов отдаётся на всех четырёх
узлах пула, по 20 штук, 120 КБ.
Сайдкар получил fetch_mode: navigate (дефолт, прежнее поведение),
subresource (context.request.get из прогретого контекста) и page_fetch
(fetch из страницы). Третий оставлен, потому что теоретически он ближе
всего к настоящему XHR, но в замере отказал — выбор сделан измерением, а
не рассуждением. Прогрев origin обязателен: рукопожатие QRATOR попадает
в куки контекста именно при заходе на страницу, поэтому свип теперь
передаёт origin и referer, которых раньше не передавал вовсе.
_decode_body распаковывает gzip по магическим байтам — карта офферов
приезжает Content-Type: application/gzip, и без этого вызывающий получил
бы бинарь в поле "html". Сама карта, к слову, подзапросом всё равно не
берётся (279 байт — загрузчик QRATOR), но BFF полнее: 100% фонда против
62% у карты.
fetch_mode кладётся в payload только когда он не дефолтный — сайдкар
прежней версии не должен получать незнакомый ключ (тот же приём, что с
referer в #3247).
Тесты: сайдкар 212 passed (новый test_server_fetch_mode.py — 6
проверок), backend 316 passed (новый test_3264_sweep_subresource_mode.py
— 5). Три тестовых дублёра _do_fetch/_post_fetch знали старую сигнатуру
— обновлены.
serp.py не передавал куки сессии вообще — слова cookie в файле не было.
Свип приходил к QRATOR с чистым браузером и был обязан решать
proof-of-work с нуля на каждый запрос. Прод, прогон 5330 (30.08
03:49-03:55): 9 запросов к bff-search-web.domclick.ru, все 9 зависли на
челлендже (перезагрузка 1/2, 2/2, отказ), status=failed, 0 лотов. Прокси
при этом ротировался (узел 9 → 10) — узел тут ни при чём.
Добор с тем же сайдкаром и тем же пулом в ту же ночь взял 37 карточек из
37 без единого блока. Разница ровно в куках.
Чинить это стало возможно только сейчас: свип ходит не на
ekaterinburg.domclick.ru, а на отдельный хост bff-search-web.domclick.ru,
и до правки _cookie_domain (PR #3262) куки легли бы на
.bff-search-web.domclick.ru, не совпав с сессией площадки. Теперь оба
хоста схлопываются в общий .domclick.ru.
Снимок приходит параметром снаружи, а не читается внутри kit: kit не
импортирует app.* (strangler-инвариант #2133). Поэтому джоба
domclick_city_sweep переопределена продуктовым Handler'ом — build_registry
это прямо допускает («последнее слово за продуктом»), а БД читает только
app-сторона.
Отсутствие сессии не авария: load_session вернул None → свип идёт как
раньше, без инъекции, факт логируется один раз.
Цена решения — override повторяет вызов kit-джобы целиком и может тихо с
ней разойтись. Добавлен тест, который зовёт оба джоба одинаково и
сравнивает наборы kwargs, допуская расхождение ровно в cookies. Проверен
мутацией: с искусственно добавленным в kit-версию аргументом краснеет,
без него зелёный.
Тесты: 245 passed, 1 skipped (domclick + parity).
Новый test_server_cookie_domain.py: схлопывание поддомена, хост из двух
лейблов без изменений, оба места инъекции зовут одну функцию.
Три существующих теста закрепляли как раз то поведение, которое оказалось
багом (.ekaterinburg.domclick.ru / .www.avito.ru / .realty.yandex.ru), —
переведены на новый контракт, докстринги объясняют почему.
Прогон сайдкара целиком: 206 passed.
Первая версия требовала >=30 файлов в fc-list и покраснела на фактических
20 — порог был взят из головы, а не измерен. Значение имеет не число
файлов (оно зависит от того, что притащили соседние пакеты), а то, что
запрос Arial отдаёт метрически совместимый шрифт. Проверяем ровно это,
по всем пяти алиасам.
Замер образа 30.08: 20 файлов, 5 семейств (Liberation Sans/Serif/Mono,
Carlito, Caladea); Arial→Liberation Sans, Times New Roman→Liberation
Serif, Courier New→Liberation Mono, Calibri→Carlito, Cambria→Caladea.
Сайдкар инжектил куки на домен из url карточки — для
ekaterinburg.domclick.ru это `.ekaterinburg.domclick.ru`. Настоящие куки
площадки живут на `.domclick.ru` (видно в записи ручной сессии 29.08:
`.domclick.ru qrator_jsid2`, `.domclick.ru qrator_jsr`).
Куки поддомена родительские не заменяют, а сосуществуют с ними: как
только площадка выдаёт свежий `qrator_jsid2` на `.domclick.ru`, браузер
шлёт в одном запросе ДВЕ куки с этим именем, и первой — более
специфичную, нашу протухшую. QRATOR читает её и держит страницу на
274-байтном загрузчике, рукопожатие не завершается никогда.
Замер 29.08, узел 10, чередование, свежий контекст на пробу:
куки на поддомене — 0 успехов из 3 (все три ровно 274 байта),
те же куки на `.domclick.ru` — 3 из 3.
Заодно шрифты в образе сайдкара: контейнер нёс 8 файлов / 3 семейства
(только DejaVu) при заявленном camoufox `os="windows"`. Добавлены
метрически совместимые Liberation/Carlito/Caladea + `fc-cache` и
build-time проверка. С текущими отказами Домклика это НЕ связано —
правка про правдоподобие отпечатка, не про этот баг.
Тестов пока нет сознательно: правка ждёт подтверждения на сервере на
отдохнувшем пуле.
PR #3258 научил якорную вкладку заходить на выдачу через поиск Яндекса, но две
ветки из трёх подставляли Referer, которого мы не заработали: «ссылку в выдаче не
нашли» ставила https://yandex.ru/, «клик увёл не туда» — URL поисковой выдачи. В
обоих случаях перехода с Яндекса на площадку НЕ БЫЛО, а заголовок утверждал
обратное.
Главная причина, по которой вторая ветка вообще срабатывала: ссылки в выдаче
Яндекса открываются в НОВОЙ вкладке (target="_blank"). Исходная страница остаётся
на Яндексе, проверка хоста не проходит — и вместо того, чтобы взять настоящую
новую вкладку, мы уходили в подстановку заголовка.
Теперь новая вкладка перехватывается: снимок context.pages до клика, сравнение
после; попап на нужном хосте становится ЯКОРНОЙ страницей (resource-block
применяется к ней — по наследству он не передаётся), вкладка с Яндексом
закрывается. Это и есть настоящий переход.
Оба фиктивных фолбэка выброшены. Не нашли ссылку, клик увёл не туда, попап не на
том хосте, капча, упавшая навигация — возвращаем None, и вызывающий идёт на origin
обычным goto БЕЗ Referer, ровно как до #3258. Принцип зафиксирован комментарием в
коде и на месте удалённой константы _YANDEX_REFERER, иначе его легко
«оптимизировать» обратно: либо переход был настоящим, либо об источнике молчим.
Тесты: 198 passed против 196 — попап на нужном хосте становится якорем и оригинал
закрыт; попап на чужом хосте → фолбэк без Referer; тест «ссылки нет» переписан, он
теперь требует отсутствия Referer вместо yandex.ru.
Якорная вкладка (#3244) открывала страницу выдачи Домклика без источника
перехода вообще. Передача referer на карточку (#3250) воспроизвела второй шаг
человеческого пути, но первый — «пришёл из поиска» — оставался невоспроизведённым.
Эталон — ручная сессия 29.08 через узел 10:
yandex.ru → клик по результату → выдача Домклика (Referer https://yandex.ru/)
→ клик → карточка (Referer = URL выдачи)
Теперь якорная вкладка идёт на yandex.ru/search, ищет среди результатов ссылку на
хост origin и КЛИКАЕТ по ней. Referer уходит не потому, что мы его подставили, а
потому, что переход действительно был.
Яндекс на мобильных прокси капризен — наблюдалась капча вживую, — поэтому
предусмотрены три контролируемых исхода, и ни один не роняет прогон:
- капча на выдаче либо упавшая навигация на Яндекс → прежний прямой goto(origin),
без referer, поведение до этой правки байт в байт;
- ссылки на хост в результатах нет → goto(origin, referer="https://yandex.ru/"):
визит на Яндекс был настоящий, заголовок честный;
- клик увёл не туда (редирект-обёртка Яндекса) → goto(origin, referer=URL выдачи),
точный адрес, а не общий yandex.ru.
Включено ТОЛЬКО для Домклика (BROWSER_ANCHOR_VIA_SEARCH=domclick по умолчанию);
Авито, Циан и Яндекс не трогаем — их проверять отдельно по #3251. Пустое значение
переменной возвращает сегодняшнее поведение целиком.
Тесты: 196 passed в сайдкаре против 191 — пять сценариев: успешный клик, откат по
капче, откат по отсутствию ссылки, провайдер вне списка, падение навигации.
Добор карточек Домклика упирался в отказ на 11-й карточке: прогон 5298 дал
attempted=13, enriched=10, blocked=3. Ручные прогоны в живом браузере брали 91 и
40 карточек без единого отказа. Разбор нашёл два отличия, и оба оказались нашими,
а не площадки.
1. Referer не отправлялся НИКОГДА. playwright'овский goto() по умолчанию этот
заголовок не шлёт, а параметр `referer`, который он принимает, мы не передавали.
Площадка видела десяток появлений подряд прямо на URL карточки, без источника
перехода — так не ходит ни один человек. Комментарии в коде при этом уверяли
про «органическую навигацию с реальным Referer»; они врали, теперь исправлены.
Сайдкар принимает `referer` в теле /fetch и ставит его ТОЛЬКО на целевую
навигацию; на origin и якорную вкладку не ставит — туда приходят «сами».
Добор Домклика передаёт страницу выдачи, чем переход и является по смыслу.
2. Зависшее рукопожатие не перезагружалось. _wait_out_pow_challenge построен на
допущении «страница перезагрузит себя сама после решения PoW»; ручная сессия
29.08 через узел 10 это опровергла — выдача осталась на 401, и пропуск
qrator_jsid2 выдался только после ДВУХ перезагрузок, сделанных руками:
102.7с GET → 401, 115.1с GET → 401, 118.4с GET → 200, следом кука-пропуск, и
карточка за 6 секунд. Пока мы только опрашивали content(), такая страница жила
до таймаута, а бэкфилл засчитывал это в блоки. Теперь после
BROWSER_CHALLENGE_RELOAD_AFTER_MS (8с) сайдкар перезагружает сам, не больше
BROWSER_CHALLENGE_MAX_RELOADS (2) раз за фетч.
Оба пути безопасны на откат: без поля `referer` в теле поведение прежнее,
BROWSER_CHALLENGE_RELOAD_AFTER_MS=0 возвращает прежний опрос без навигаций,
упавшая перезагрузка не роняет фетч — опрос продолжается в том же бюджете.
Тесты: 191 passed в сайдкаре (было 182) — 4 на Referer, 5 на перезагрузку, в том
числе «страница ожила сама → лишней навигации нет» и «висит вечно → не больше
лимита». Точечные backend-тесты домклика и scraper_kit — 144 passed.
Экран проверки дорисовывал результат НИЖЕ формы и никуда не уводил: на 375 px
человек после нажатия видел ту же форму, а заголовок ответа оставался за нижней
кромкой — нажатие читается как «ничего не произошло». Ответ теперь получает
фокус и прокрутку; анимация прокрутки спрашивается у prefers-reduced-motion, той
же медиа-функции, что глушит остальную анимацию витрины. Фокус здесь не
украшение: без него клавиатурный пользователь остаётся на кнопке и следующим Tab
уходит в обход ответа, а живая область объявляет текст, но не перемещает точку
ввода.
Второе: в дропдауне девять городов, и они не равны по данным, но узнать об этом
можно было только ПОСЛЕ нажатия. Замер на проде (30.08.2026, симуляция когорты
самой ручки /coverage по случайным адресам активных объявлений, собственный
адрес исключён): доля проверок с выборкой не ниже городского порога — ЕКБ 83 %,
Верхняя Пышма 70, Серов 58, Нижний Тагил 52, Первоуральск 50,
Каменск-Уральский 45, Среднеуральск 39, Берёзовский 38, Ревда 16 (по 120
адресов, Среднеуральск — 56, столько их там есть). Величина и её источник лежат
в landing-facts.ts, формулировка — в coverage-copy.ts, в компонент не вписано
ни одного числа.
Города из списка НЕ убраны: систематического отказа нет ни в одном (пустая
когорта у худшего — 11 случаев из 100), разница между ними количественная, и её
честнее назвать числом, чем снятием опции. Счёт по listings.city, дающий ноль по
трём городам-спутникам, здесь не годится — колонка хранит город свипа скрейпера,
а не геокод объявления (разбор над _CITY_CENTROIDS_DEG в trade_in.py).
Тест требует замера на каждый город из OBLAST_CITIES — добавить город в дропдаун,
не измерив его, теперь нельзя.
Аудит живого сайта 30.08.2026: POST /api/public/mera/coverage с
{"lat":56.8,"lon":1e400,...} отвечал 500, и двенадцать таких запросов подряд
дали двенадцать пятисоток и ни одного 429. Две независимые поломки в одном
месте, обе воспроизведены локально до правки.
1. 500 вместо 422. json.loads принимает Infinity/-Infinity/NaN, а 1e400 даёт
inf переполнением. Pydantic отбивает такое поле по границам и кладёт
значение в input ошибки, а ответ об ошибке сериализуется
json.dumps(allow_nan=False) и падает уже после входа в ответ. Ломается не
поле, а сборка ответа об ошибке — одна на всё приложение, поэтому и
обработчик один (app/core/http_errors.py), а не валидатор на lon.
2. Лимитер мимо. _enforce стоял первой строкой тела хендлера, а FastAPI
валидирует тело позже зависимостей, но раньше тела — до проверки просто не
доходило. Та же поправка места, что уже сделана сегодня у
_require_public_estimate_enabled: перенос в dependencies. Сделано для всех
ручек файла, не только coverage. У /estimate и /estimate/read флаг остаётся
первой зависимостью — 429 на выключенной ручке подтверждал бы её
существование.
Тесты двусторонние: снятие обработчика роняет 4 проверки 422, возврат лимитера
в тело роняет проверку бюджета (проверено).
Витрина показывала fact_rub = price_per_m2 * area_m2, хотя deals.price_rub
лежит в той же строке и не использовалась. price_per_m2 в базе integer,
поэтому под подписью «Цена ДКП» ехала реконструкция: 4 799 995 вместо
4 800 000, 3 649 995 вместо 3 650 000 (прод, сделки 5777343 и др.).
Теперь price_rub едет из выборки (DealSample.price_rub) и показывается как
есть; err_pct считается от той же величины. Строка без price_rub НЕ
показывается — подставлять реконструкцию в одну строку из двадцати значило бы
спрятать тот же дефект (на проде price_rub заполнен у 33 555 из 33 555 сделок
выборки витрины).
Вторая находка аудита (listing_date якобы «когда увидели МЫ», экспозиция
занижена втрое) НЕ ПОДТВЕРДИЛАСЬ. listing_date пишут cian (added_ts), yandex
(creationDate) и avito (дата карточки выдачи) — это дата публикации у
источника. Там, где заполнены и listing_date, и publish_date, они совпадают:
yandex 10 761 из 10 903, avito 474 из 569, медиана разницы 0 дней. 75 дней у
аудитора — эффект другой ВЫБОРКИ: publish_date есть у 15 058 активных строк
(yandex + Домклик, оба старые), listing_date — у 25 982 (плюс cian с медианой
17 дней и 87% avito с медианой 19).
Настоящий дефект рядом: по одному listing_date Домклик выпадал целиком (0 из
3061 активной строки), метрика считалась по 83.6% активных объявлений, и
подпись об этом молчала. COALESCE(listing_date, publish_date) → охват 95.2%
(29 568 из 31 068), медиана та же — 26 дней; охват теперь назван в note.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
