Контроль изменений — пятница, 21 августа

Самое крупное изменение в этом релизе берёт 407,302 страницы деталей, на которых нет ничего — ни цены, ни фото, ни данных каталога, — и заставляет их отвечать «страница не найдена» вместо пустой страницы. Замысел верный, и делать это стоит. Но в правиле два списка, и только один из них проверяет, есть ли на странице хоть что-нибудь. 7,803 страницы, на которых что-то есть — у 4,828 из них настоящая цена, в сумме $3,888,976.50 по прайсу, — снимаются заодно.

Это нашли в четверг, просто открыв одну из них: деталь New Holland Construction, которую прод сегодня отдаёт по $42.42 / each, со списком совместимости, восемью ссылками на схемы и кнопкой “Свяжитесь с отделом запчастей”. На кандидате тот же адрес отвечает «страница не найдена».

Что при этом тоже верно Ни по одной из 407,302 не было заказа за двадцать четыре месяца. Ни одна не отдаётся в Google. Ни одну нельзя найти поиском по самому магазину. А схема деталей на них уже не ссылается, так что выкатка не создаёт ни одной битой ссылки и не ломает ни одного пути к покупке внутри магазина. Клиент теряет страницу с ценой и телефоном, а не возможность что-то купить.

Выбор Выкатить как есть и согласиться, что 4,828 страниц с ценой перестанут существовать, — или до пятницы перенести одно слово из одного списка в другой: это сохраняет 98.1% результата и оставляет те 7,803 страницы живыми. Сам пул-реквест называл эту правку компромиссом, на который стоит взглянуть ещё раз; её просто ни разу не проговорили вслух.

Чего это не отвечает: никто не мерил, сколько людей на самом деле открывает эти 4,828 страниц. Для этого нужна выгрузка из Search Console, а вход в облако для неё в четверг был просрочен — это недостающее измерение, а не ноль.

Прод сегодня — человек видит этоКандидат

За эту сессию я не смог прочитать ни одного имени ревизии Cloud Run, ни распределения трафика, ни переменной окружения, ни значения масштабирования на уровне сервиса. Токен просрочен; по действующему правилу просроченный токен — это ложноотрицательный результат, а не доказательство отсутствия. Чего из-за этого не хватает для отката: имени ревизии search-api, которая обслуживает трафик сейчас (это и есть реальная цель отката через --to-revisions), ответа на вопрос, совпадают ли сегодня latestReady и latestCreated на search-api, есть ли припаркованный устаревший тег трафика (он тарифицируется, и такое случалось дважды), переменных окружения search-api (подмена образа сохраняет окружение, поэтому переменная, которая нужна новому образу и которой нет на проде, = падение в цикле перезапусков), и тега развёрнутого образа по каждому сервису parts-services. Два факта у меня всё же есть, из ops/docs/evidence/2026-08-20-search-promote-before.json, снятого сегодня в 07:35:01Z, пока gcloud ещё работал: на проде search-api крутит образ search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab со scalingMode MANUAL / manualInstanceCount 2; search-api-dev крутит crop-search:b92268a1a3551b8c7485ce9cf88995edce7231ed с maxInstanceCount 2. Это тег образа, а не имя ревизии — имя ревизии из него не вывести.

Что делатьВова, после gcloud auth login выполни ровно это и вставь вывод на страницу change-control: (1) gcloud run services describe search-api --region=us-east1 --format='value(status.latestReadyRevisionName,status.latestCreatedRevisionName)' (2) gcloud run services describe search-api --region=us-east1 --flatten='status.traffic[]' --format='csv[no-heading](status.traffic.revisionName,status.traffic.percent,status.traffic.tag)' — это даёт имя ревизии для отката И показывает устаревший тег, если он есть (3) gcloud run revisions list --service=search-api --region=us-east1 --format='table(name,active,creationTimestamp,spec.containers[0].image)' (4) gcloud run services describe search-api --region=us-east1 --format='yaml(spec.template.spec.containers[0].env)' — проверь IS_PUBLISHABLE_FILTER_ENABLED и все переменные, которые нужны новому модулю конфигурации (5) curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" https://run.googleapis.com/v2/projects/noted-bliss-466410-q6/locations/us-east1/services/search-api — это вызов v2 REST, потому что describe отдаёт spec.scaling как null и СКРЫВАЕТ лимит инстансов на уровне сервиса (именно поэтому ops/scripts/search-promote-check.ts ходит через REST) (6) gcloud run services list --region=us-east1 --format='table(metadata.name,status.latestReadyRevisionName,spec.template.spec.containers[0].image)' — теги образов parts-services (7) bun run ops/scripts/search-promote-check.ts, чтобы обновить инструмент «до/после», когда авторизация вернётся.

Путь в Artifact Registry переименовали 2026-08-19, посреди недели, между прошлой выкаткой и этой. Цепочка — из диффа #916, который я прочитал сам: search-hono-nest -> search-nest -> crop-search, всё внутри us-east1-docker.pkg.dev/noted-bliss-466410-q6/cloud-run-source-deploy/. То есть выкатка пушит crop-search:<dev sha>, а откатываться надо НА search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab — это другое имя репозитория, что независимо подтверждает сегодняшний утренний JSON с замерами. В самом workflow из #916 так и написано: «откат обязан использовать тот путь, под которым этот SHA был собран, а не текущий». Раннбук delivery-flow повторяет то же самое. Ловушка в том, что подмена тега по пути crop-search на 2da1a51e не разрешается ни во что, и Cloud Build падает — ровно в тот момент, когда ты пытаешься отменить неудачную выкатку. Безопасный откат вообще не трогает образы: gcloud run services update-traffic search-api --to-revisions=<prev-revision>=100 --region=us-east1, потому что каждая ревизия остаётся доступной по имени, пока её не удалили. Для этого нужно имя ревизии, а оно НЕДОСТУПНО (см. пункт про gcloud).

Что делатьВова: до подмены сними имя ревизии, которая обслуживает трафик сейчас, и запиши на страницу change-control И имя ревизии, И полный URI старого образа (us-east1-docker.pkg.dev/noted-bliss-466410-q6/cloud-run-source-deploy/search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab). Откатывайся по ревизии, а не по образу.

Замерял сам сегодня примерно в 12:54-13:05Z, с UA краулера, запросами, которых раньше не было. Прод search-api /health — самая дешёвая ручка, какая есть, пинг базы без федеративного веера — ответил: таймаут на 40s, таймаут на 40s, потом 200 за 38.77s. Дев search-api /health ответил 200 за 0.62s, со здоровым кэшем словаря. Это не форма веера из #895/#896; /health веера не делает. Важнее другое: КОНТРОЛЬНЫЙ путь из #924 тоже отвалился — https://crop.clintontractor.net/parts?page=10 вернул 500 три раза из трёх (20.08s, 5.39s, 2.56s), тогда как в 01:15Z он отдавал 200 за 0.78-0.96s и был приведён в #924 как доказательство того, что «каталог здоров, падает только поиск». Больше это не так. Ещё замеры: / = 200 за 5.53s, /parts (без параметров) = 200 за 4.61s, карточка детали /parts/CT-NHL-100074 = 200 за 19.11s. Поэтому, по правилу из брифа, говорю прямо: сегодня я не могу отделить «поверхность выкатки» от «живой аварии», потому что авария дошла и до обычного списка каталога. Любое «до/после», которое ты снимешь в пятницу, будет мериться относительно плывущей, ухудшающейся базы — а окно «до/после» умирает в момент выкатки.

Что делатьВова: прогони bun run ops/scripts/search-promote-check.ts прямо перед выкаткой, чтобы обновить «до», а утренний JSON от 07:35Z считай устаревшим. Если на момент выкатки /health всё ещё 38s+, реши явно, можно ли вообще доверять прохождению проверки кандидата — /health на 40s не переживёт smoke-candidate.sh.

Недельная выкатка фронта — это merge stage -> main по docs/runbooks/delivery-flow.md. HEAD у stage — это e6b2f0f99, датирован 2026-08-14T06:14:24Z, сообщение 'chore(stage): re-cut release train 2026-08-13 from dev [preview]'. compare/main...stage = 2 впереди, 93 позади, 0 изменённых файлов; compare/stage...dev = 89 впереди. То есть на stage лежит поезд прошлой недели и ничего из этой. Сегодня четверг 2026-08-20, это и есть день среза, и по состоянию на 13:00Z срез не сделан. Значит, всё, что идёт после среза, тоже не сделано: приёмки QA на stage не было, а в CROP-change-control лежат только 2026-08-07.html и 2026-08-14.html — страницы под этот поезд нет, а именно она и есть материал для пятиминутного ретро с Джоном.

Что делатьВова: сегодня же срежь stage с зафиксированного SHA dev — или прямо сейчас реши, что в пятницу выкатывается только поиск, и скажи об этом вслух: фронтовую половину нельзя проверить на stage, который отстаёт от dev на 89 коммитов.

Пятничная выкатка подменяет образ на тот артефакт, который благословила проверка на DEV. HEAD dev она не благословила. Прогон 32347365459 (Deploy search-api-dev, dev sha 678b7af2 = #925, сегодня в 08:08Z): 'Build image' — успех, 'Deploy candidate revision (no traffic)' — успех, 'Smoke + warm + contract gate vs candidate' — ПАДЕНИЕ, 'Promote candidate to 100% traffic' — ПРОПУЩЕН, 'Delete un-promoted candidate on gate failure' — успех. Предыдущий прогон (f5518b6b, 07:38Z) прошёл. То есть search-api-dev сегодня отдаёт образ f5518b6b — в нём есть #920 (кэш трёх самых горячих маршрутов assemblies) и #922 (part_count для Kuhn), но НЕТ #925 (ограда для узлов CNH). Третий прогон (24b775a4, 07:38Z) тоже упал. Это ровно то тихое устаревание, которое описано в #910: workflow работает как задуман, ничто не алертит, а старая ревизия продолжает обслуживать трафик. ops/docs/2026-08-20-merchant-feed-promote.md добавляет вторую половину: smoke-candidate.sh ходит в dev-crop-db, а это и ЕСТЬ прод-PG, поэтому прогон проверки внутри окна со ~100% CPU падает на обычном просмотре каталога, и повтор в том же окне уходит впустую. Пятница, 05:00 по Нью-Йорку = 09:00 UTC: максимум 97.9% 08-17 и 94.0% 08-18.

Что делатьВова: перед подменой посмотри CPU прод-PG за предыдущие 30 минут; если он упёрт в полку — жди, а не перезапускай. Потом перезапусти деплой на dev с HEAD dev и убедись, что проверка -> выкатка -> паритет терминальной страницы зелёные все три и latestReady == latestCreated. Только после этого подменяй. И реши явно, что именно подменяешь: HEAD dev (нужна зелёная проверка) или образ f5518b6b (зелёный, но без #925).

Замерено 2026-08-20 примерно в 13:00Z, запросами, которых раньше не было. Прод /api/search: первая проба — ответа нет за 45s, вторая — 200 за 32.4s. search-api-dev на ТОЙ ЖЕ базе: 200 за 5.67s и 4.00s. Сам /health на проде занял 39.6s; на деве /health — 0.60s. Витрина /parts?q=<fresh> — 500 за 16.8s. Новое, чего нет в #924: /parts?page=2 — 500 за 3.1s, /parts?page=10 — 500 за 2.9s и 5.3s, при этом /parts страница 1 — это 200 за 4.7s, а главная — 200. В #924 записано: «каталог здоров, /parts?page=10 отдаёт 200 за 0.81s» — это больше не так, значит видимая покупателю поверхность шире, чем говорит тикет. Страница 1 закэширована на CDN; всё, что не из кэша, падает. Отсюда же следует, что сегодня прод-500 почти на любом пути каталога — это та же авария, а не новая регрессия: разделить их на некэшированном маршруте я не смог.

Что делатьВова: лечение — это подмена образа. Добавь /parts?page=2 в критерии приёмки в search#924 (сейчас там только ?q=) и перемерь сразу после подмены. Если страница 2 не оживёт, у аварии есть вторая причина, и остальные пятничные выкатки надо остановить.

Ограничение сформулировано в теле самого #3653: «обе строки brand-hold должны быть на main ДО того, как на проде выставят PDP_INDEXING_MODE=strict — если сначала переключить переменную окружения, откроются четыре несогласованных бренда (Kuhn / Ferris / McHale / Marcrest, 358 деталей, подходящих для реестра). Сначала cherry-pick, потом переменная, именно в таком порядке, на поезде 2026-08-21.» #3244 влили днём позже, и он переключает ЗНАЧЕНИЕ ПО УМОЛЧАНИЮ на strict в lib/seo-config.ts — то есть, как только он на main, никакого шага с переменной, который мог бы придержать, уже не остаётся: strict приезжает вместе с деплоем. #3244 заодно убивает legacyBrandHold (он завязан на mode !== strict) и прямо об этом пишет. Обоснование в #3244 — «PDP_INDEXING_MODE=strict на проде и так выставлен, поэтому поведение прода не меняется». Замеры этого не подтверждают: на проде /sitemap/1.xml содержит 2,378 locs, и все 2,378 из них — CT-NHL-, ни одного FER/KUH/MCH/MAR; прод /parts/CT-FER-1608395 отвечает 200 с noindex, follow. По детектору строгого режима из самого #3625 («любой loc с не-CNH брендом означает, что удержание снято») удержание сегодня на проде ВКЛЮЧЕНО. Прочитать значение переменной в Vercel, чтобы понять, какой из двух PR прав, я не смог — значения переменных окружения отсюда не читаются.

Что делатьВова: до поезда прочитай реальное значение PDP_INDEXING_MODE в Vercel Production (vercel env ls production или в панели). Дальше либо переноси #3653 и #3244 одним набором изменений, либо придержи #3244 целиком. Один только #3244 открывает четыре бренда, которые Джон не согласовывал.

#615 добавляет validateCheckout в POST /payment-intent — это путь Apple Pay / Google Pay / Link — и на каждую строку корзины делает по одному GET /api/parts/:id в поисковый сервис, падая ЗАКРЫТО. Холодный поиск на проде сегодня отвечает за 32s; у fetchPartPrice в payment-service таймаут 5s. Хостовая страница оформления заказа уже падает ровно так же: в ops/docs/2026-08-20-checkout-blocked-by-pg-saturation.md записано, как crop-checkout-probe (настоящий POST /api/checkout/session по проду каждые 30 мин) провалил три запуска по расписанию 08-19 с 'Could not verify price for CROP-SYNTHETIC-PROBE (search API timeout)', политика p0, алерт сработал пять раз, не пришёл никто. Express Checkout сейчас — единственный платёжный путь, который ещё работает, ровно потому, что он не ходит в каталог. Если сначала выкатить #615, этого пути не останется.

Что делатьВова: сначала подмена образа search-api, с подтверждением зелёного на свежем холодном запросе, и только потом ps#615. Порядок не обсуждается. Если подмена сдвигается, ps#615 сдвигается вместе с ней.

В ops/docs/2026-08-20-merchant-feed-promote.md это записано как жёсткий барьер: «явная приёмка QA от Дениса на stage — жёсткий барьер. Нет приёмки — нет выкатки, поезд ждёт неделю». Денис уволился 2026-08-20. Семь мерджей этой недели в dev идут с Driver: @denistka, среди них два видимых покупателю изменения по наличию (front#3565, search#891) и два изменения на денежном пути (ps#615, ps#624). Никто не назначен подписывать приёмку на stage в пятницу, а барьер, который по умолчанию проходят, хуже, чем его отсутствие.

Что делатьВова: до пятницы либо назначь приёмщиком на stage себя и сам пройди проверку, либо убери этот барьер из delivery-flow.md и запиши, что приходит ему на замену. Не давай поезду уехать с галочкой, которую никто не поставил и никто не заметил.

front#3653 (мердж 65e71f00c7, 08-18) сделал удержание брендов независимым от режима; front#3244 (мердж fa60043144, 08-19) переключил значение PDP_INDEXING_MODE по умолчанию с legacy на strict. Это отдельные коммиты, а по домашнему правилу cherry-pick оформляется отдельным PR — значит, они могут приехать порознь. Сегодня проверено на origin/main: lib/seo-config.ts по-прежнему возвращает "legacy" по умолчанию, lib/seo/pdp-index-hold.ts начинается с if (PDP_INDEXING_MODE === "strict") return false;, а app/parts/[id]/page.tsx:223 завязывает legacyBrandHold на PDP_INDEXING_MODE !== "strict". На origin/dev обоих исключений уже нет, и isBrandHeldSku работает безусловно. То есть перенести один только #3244 = карточки Kuhn/Ferris/McHale/Marcrest плюс обе карты сайта уходят в index,follow — а по #3653 это 358 деталей из реестра, которые Джон не согласовывал. Тела двух PR приходят к противоположным выводам: #3244 называет отмирание удержания "намеренным и правильным", #3653 называет это четырьмя несогласованными брендами. Ревьюер, который читает только #3244, одобрил бы его сам по себе. Вторая ловушка: строка из раннбука в #3653 — "сначала cherry-pick, потом переменная, именно в таком порядке" — теперь наполовину устарела: #3244 втянул PDP_INDEXING_MODE=strict в код, так что сам перенос и есть переключение, и барьера на переменной в этой половине не осталось. Реально остаётся один шаг с переменной — ENABLE_EQUIPMENT_TREE_NOINDEX=true (всё ещё === "true", по умолчанию выключено, проверено на dev). Ни один открытый тикет эту связку не несёт; #2912 и #3594 оба закрыты.

Что делатьВова: собери фронтовый поезд 08-21 так, чтобы lib/seo-config.ts, lib/seo/pdp-index-hold.ts и app/parts/[id]/page.tsx приехали ОДНИМ cherry-pick PR, и поправь строку про порядок в docs/seo/index-open-runbook.md, пока по ней кто-нибудь не пошёл. После выкатки дёрни curl -A crop-audit по карточке KUH/FER/MCH/MAR и убедись, что там noindex, follow.

Замерено сегодня с -A crop-audit по проду: /robots.txt — 200 за 0.66s, /sitemap/1.xml — 200 за 0.34s, в нём заявлено 2,378 locs карточек, / — 200 за 6.4s, но /parts?q=<never-used-string> вернул 500 за 20.2s, /parts/CT-NHL-219758 не ответил за 40s, а /parts/CT-NHL-100016 (взят прямо из той же карты сайта) отвечал 19.0s, прежде чем отдать 200. На одной пробе номер детали Ferris вернул 500 за 63s. То есть вся индексируемая поверхность, которую мы сами отдаём на индексацию, сейчас отвечает краулеру медленно или с ошибкой. Отдельно: на HEAD dev фронта (ce2513b7) падают build, lint-and-build и crawl-preview: прогон 32348291522, задача build, 08:33Z — видно, что /api/brand/{mchale,marcrest,new-holland-agriculture,ferris,kuhn,kress,landoll}/equipment-types каждый раз возвращает errorStatus 429, retry-exhausted, adaptive-backoff healthy -> recovering. Это та же зависимость от прод-поиска, ради которой заведён front#3707. Следствие, которое никто не записал: пока CI на dev красный из-за этого, ни один cherry-pick PR в main не станет зелёным, значит фронтовый поезд идёт после подмены образа, а не параллельно ей. ops/scripts/search-promote-check.ts уже есть, и окно «до» по нему снято (ops 1960680).

Что делатьВова: сначала подмена образа по search#924, проверка через bun run ops/scripts/search-promote-check.ts (сначала статус, потом задержка; запрос, которого раньше не было), затем перезапуск CI фронта на dev — и только потом сборка поезда.

Маршрут A — недельный поезд из раннбука: merge stage -> main, который после свежего среза несёт compare/main...dev = 88 коммитов / 300 файлов. Это вся неделя целиком — SEO-поезд (#3653, #3700, #3661), расширение товарного фида (#3655, #3650, #3690), работа по наличию и карточкам, перестройка CI. Маршрут B — то, что реально открыто против main прямо сейчас: пять cherry-pick PR: #3680, #3679, #3675, #3662, #3638 — и каждый из них починка CI или проверки (холодный старт sitemap-seo-gate, красные прогоны по расписанию, preflight на цель stage, вычитание brand-hold, обход автоматизации Vercel). Ни один из них не трогает код, который видит покупатель. Отдельно стоит проговорить: ни у одной фронтовой починки текущей аварии — #3712 (отвечать на временный сбой поиска как на аварию, а не 500), #3684 (сбой поиска не должен читаться как снятый с продажи каталог), #3628 (деградировавший каталог доезжает до краулера как 503, а не 500) — нет открытого cherry-pick PR. Они живут только на dev. То есть на маршруте B собственная устойчивость витрины к сбою поиска до прода не доезжает.

Что делатьВова: скажи вслух до созвона, какой маршрут в пятницу. Если это маршрут B, скажи прямо, что витрина продолжит отдавать 500 при сбое поиска, потому что #3712/#3684/#3628 в него не входят.

Ответ на вопрос 3, первый настоящий пункт. #3700 превращает 407,302 страницы деталей в 404 на CDN, в lib/proxy/supersession-redirect.ts. Я прогрепал весь его дифф в поисках флага — process.env встречается ровно один раз, как deps.baseUrl ?? process.env.SEARCH_SERVICE_URL. Фиче-флага нет: это уезжает вместе с выкаткой. Необратимая часть — обход Google: URL, которые он обошёл и получил на них 404, пока изменение было живым, — это уже отправленный сигнал, и откат кода его не отзовёт. Ущерб ограничен двумя вещами, и обе не предположены, а измерены в самих PR. Первое: все 407,302 уже is_publishable=false и уже noindex, как написано в теле #3700, так что проиндексированное множество почти не двигается — это работа с краул-бюджетом, а не деиндексация ранжирующихся страниц. Второе: #3710 намеренно ограничивает TTL на CDN значением s-maxage=300 (иначе он унаследовал бы от /parts-not-found s-maxage=3600 + 24h stale-while-revalidate), так что откат возвращает 200 за пять минут, а не за сутки. 13,626 строк dont_list, у которых есть цена или картинка, остаются 200.

Что делатьВова: в пятницу явно прими это или придержи. Если принимаешь — запиши на странице change-control, что откат здесь это «код плюс пять минут на CDN», а не мгновенно, и что верно это только благодаря #3710: он обязан ехать в той же выкатке, что и #3700, и никогда после него.

compare/main...dev = 8 коммитов впереди, 56 файлов. HEAD main — be865716b от 2026-08-14T07:07:30Z (#616, поезд 08-13); HEAD dev — 38352042f от 08-18. Двое из восьми трогают деньги. #615 (3323f61c7) пересчитывает цену корзины express-checkout по каталогу до списания — он меняет services/payment/src/routes/payment-intent.ts, то есть то, сколько спишут с покупателя; #624 (38352042f) не даёт выдать ответ UPS без блока стоимости за бесплатную доставку. Сам по себе ни один из них не необратим (наружу ничего не пишется; по действующему правилу наш код никогда не ходит в Stripe за возвратами), но оба меняют то, что покупателю говорят и сколько с него берут, поэтому откат после реальных заказов оставит эти заказы посчитанными по той версии, которая была живой. #620 — это подъём Bun 1.3.9 -> 1.3.14, лекарство от утечки TLS, из-за которой четыре сервиса ловят OOM; пожалуй, именно его больше всего хочется видеть на проде. Отдельно: четыре PR на выкатку в main стоят в очереди с 08-11/08-12 и не двигаются: #600 (перебор простаивающих соединений Mongo / OOM), #596 (запись в кэш на /rates, P0), #595 (скрипт бэкфилла), #594 (brand_code при загрузке фото). Обрати внимание на предупреждение из самого раннбука: git log origin/main..origin/dev здесь завышает — он говорит 8, а git cherry -v по patch-id говорит 6.

Что делатьВова: реши, едет ли parts-services в пятницу вообще. Если да — это отдельные cherry-pick с зафиксированного SHA поезда, ни в коем случае не мердж dev->main, и #620 идёт первым, потому что он и есть лекарство от OOM. Если нет — скажи об этом: #596 и #600 стоят в очереди девять дней, и это должно быть решением, а не самотёком.

docs/runbooks/delivery-flow.md называет три барьера перед выкаткой: явная приёмка QA от Дениса на stage (жёсткий — нет приёмки, нет выкатки, поезд ждёт неделю); ноль открытых тикетов release-blocker; и никаких выкаток на прод в рабочие часы. Второй я проверил: gh issue list --label release-blocker --state open по CROP-front, CROP-search и CROP-parts-services не возвращает ничего — этот барьер чист. В CROP-search открыты два тикета класса sale-blocker: #924 (это и есть данная выкатка) и #146 (баг с фитментом в описаниях BOM, отнесён Джоном, к делу не относится). Проблема в первом барьере: за QA никто не отвечает, да и подписывать нечего — сборки на stage нет (см. пункт про stage). Прошлая выкатка уже уехала за пределы окна рабочих часов по решению Вовы и была записана в ops/docs/change-control/emergency-log.md.

Что делатьВова: реши, кто подписывает приёмку, или явно откажись от этого барьера для выкатки только поиска — и запиши отказ в emergency-log.md так же, как записали внеоконную выкатку 08-14 в прошлый раз. Жёсткий барьер без владельца, через который все тихо переступают, хуже, чем барьер, от которого отказались официально.

search#924 формулирует размен своими словами: «подмена образа — это всё или ничего: выкатка везёт все 27 коммитов, а не только #896/#897. Работа по SEO-поезду, изменение товарного фида (#904) и изменение оси склада в наличии (#891) едут вместе с ней. Именно это и надо взвесить; но это не повод оставлять на проде поиск на 16.5s.» Взять одну только починку задержек нельзя. Сейчас прод search-api крутит search-nest:2da1a51e (по базовому замеру 07:35Z в ops/docs/evidence/2026-08-20-search-promote-before.json).

Что делатьВова: либо принимаешь весь набор, либо не подменяешь. Если принимаешь — пункты 7, 10 и 15 ниже это три попутчика, которые реально меняют то, что видит покупатель, и назвать их надо на встрече, а не обнаружить потом.

#891 перестаёт брать наличие для схемы деталей с выведенной из оборота оси cnh_orderability и читает сигнал склада через тот же resolveRowAvailability, что и плитка каталога. Известная группа: 127,404 публикуемых строк на схеме переезжают с зелёной плашки In Stock на Out of Stock (эта цифра — из работы по #708, а не из этого PR). В самом PR прямо сказано, что изменение ШИРЕ: любая строка BOM без показаний склада и с Material Status GREEN раньше читалась как in_stock, а теперь читается как «непонятно» — «это вторая группа, это не 127,404, и её никто не считал». Тело PR заканчивается словами «@appdev-v — пожалуйста, прогони эти [два SQL-счётчика] до мерджа». Его влили 2026-08-16 без них. front#3562 добавляет защиту на стороне витрины, чтобы кнопка «добавить всё, что в наличии» не открыла это заново, и отдельного решения не требует.

Что делатьВова или Алекс: прогони два счётчика из тела #891 по прод-PG до подмены. Именно вторую цифру (зелёная плашка -> «мы не знаем») должен услышать Джон — и именно её ни у кого нет.

Эти два работают только вместе. #3700 отдаёт 404 на CDN для всех строк no_cnh_data плюс для строк dont_list без цены и без картинки: 407,302 URL переезжают с 200 / 286 KB / 11.2s на 404 / ~104 KB / меньше секунды. Сделано намеренно, но не бесплатно: 7,804 из 75,048 строк no_cnh_data содержимое ВСЁ-ТАКИ несут (4,829 с ценой, 3,841 с картинкой) и всё равно отдают 404 — сам PR помечает это как «единственную цифру здесь, которая не выглядит очевидно бесплатной», а сделать поведение зависимым от содержимого — это правка в одну строку в WITHDRAWN_STATUSES. publish_status пересчитывается КАЖДУЮ НОЧЬ, так что URL может законно ходить 404 -> 200 -> 404 от ночи к ночи. #3710 ограничивает TTL на CDN значением s-maxage=300; без него 404 наследует s-maxage=3600 + stale-while-revalidate=86400 (замерено на dev: x-vercel-cache HIT, age 84), и деталь, которая за ночь стала продаваемой, продолжает отвечать 404 до 25 часов.

Что делатьВова: реши, будут ли 7,804 строки no_cnh_data с содержимым отдавать 404. Потом вези #3700 и #3710 одним набором изменений — или не вези ни одного. После выкатки следи за pdp.unpublishable_404: там нужен ступенчатый сдвиг, а не медленный дрейф.

Всё закрыто за PDP_INDEXING_MODE=strict и новой ENABLE_EQUIPMENT_TREE_NOINDEX (по умолчанию выключена, зарегистрирована в .env.example + lib/seo-config.ts, а НЕ в lib/env.ts — значение в Vercel это часть поезда). На мердже не меняется ничего; оба переключателя сегодня выключены/в legacy. Замерено на проде сейчас: карта сайта заявляет 18,657 URL — шард 0 = 16,279 locs, из которых 16,250 это /equipment*, шард 1 = 2,378 карточек деталей. После переключения остаётся примерно 2,407 (2,378 карточек + 16 списков брендов + 2 хаба брендов + 11 статических), а 352,201 карточка + 8,126 страниц техники + 8,124 хаба схем переезжают с index,follow на noindex,follow. Все эти страницы по-прежнему отвечают 200 и по-прежнему находятся поиском по сайту. Откат — только через переменные окружения, без деплоя: PDP_INDEXING_MODE=legacy, ENABLE_EQUIPMENT_TREE_NOINDEX=false, вернуть DIAGRAM_NOINDEX_PILOT_FAMILIES, переразвернуть текущую сборку.

Что делатьВова: выставь обе переменные в Vercel Production ПОСЛЕ того, как код приедет, а не до. И скажи Джону, что число в карте сайта уходит с 18,657 -> ~2,407 ещё до того, как он увидит это в GSC, и что подготовленный список потом сам дорастает примерно до ~11,800 без единой правки в коде.

search#904 переводит источник фида с indexable_parts_v1 + merchant_eligible (там нужно clinton_on_hand > 0, отсюда и потолок в 2,684) на part_indexing_candidates_v1 + проверки по картинке/офферу/коммерции: 97,578 строк, ширина шарда 5,000 -> 25,000. front#3655 переписывает маршрут под это: 4 шарда по 25,000, id по каноническому SKU, картинки галереи >=500x500, сопоставленные категории Google, g:shipping убран. ops/docs/2026-08-20-merchant-feed-promote.md: «сначала search-api, фронт вторым. Растяжка batchSize на фронте роняет фид в 503, если фронт приедет раньше бэкенда, в который он ходит». Замерено на проде сейчас: /feed/google/0.xml = 2,632 позиции за 0.28s, /feed/google/1.xml = 503, /feed/google/inventory/0.xml = 404 — ни одна половина не живая. front#3690 чинит ещё пять дефектов с пустыми строками и кодировкой, которые внёс сам #3655, и обязан ехать вместе с ним. Если вместо поезда stage->main использовать cherry-pick хотфиксом, закрытие — это три коммита СТРОГО ПО ПОРЯДКУ: сначала b90bac5ae (он добавляет canonicalSkuPath, которого на main нет; без него два других переносятся чисто, а потом не компилируются), затем a97fb36a4, затем 4c5f8456f, плюс #3690.

Что делатьВова: сначала подмена на бэкенде с проверкой, потом фронт. Сразу после этого прогони bun run scripts/merchant-feed-audit.ts по проду. И учти: аккаунт Merchant Center так и не создан (только через консоль, это на тебе) — фид может быть идеальным и при этом не дойти ни до кого, пока аккаунта нет.

#3655 говорит об этом прямо: цены — это разовая апрельская загрузка, средний возраст примерно 95 дней, и 15,345 продаваемых деталей стоят НИЖЕ живой цены CNH (ops/docs/evidence/2026-07-20-nh-price-correctness.md). Переход с 2,635 позиций на 97,578 проблему не создаёт, но умножает подверженность ей в 37x. Ведётся с Алексом как hub#305, не закрыто. Отдельно: 1,584 из 97,578 — это федеративные бренды, чьи карточки отвечают 200 с noindex, follow; 353 из них уже есть в сегодняшнем фиде, так что они остаются, но коды причин стоит проверить при первом чтении Diagnostics.

Что делатьВова: реши, уходит ли фид в бой до закрытия hub#305 или нет. Если да — назови цифру вслух на встрече: 15,345 деталей стоят дешевле живой цены CNH — чтобы это был принятый риск, а не находка.

Googlebot убирают с блокирующего бот-рендера в Next и переводят на путь через CDN. Замерено на проде: Googlebot получал x-vercel-cache BYPASS за 0.87-4.52s против HIT за 0.20-1.40s у браузера, причём head и body побайтово одинаковые — то есть блокирующий рендер не дал ничего, зато ограничивал скорость обхода. Переопределение htmlLimitedBots и workflow, который следил за его расхождением, удалены. Это изменение поведения для краулеров на всём сайте, и оно приезжает в момент деплоя кода; переключателя в переменных окружения нет. Два поддерева намеренно оставляют старый блокирующий рендер (/parts-diagrams/<brand>/<model> и /brand/<slug>), потому что их 404 существует ТОЛЬКО благодаря бот-рендеру — #3621 переносит оба на CDN и тоже лежит на dev, и именно это позволит со временем убрать исключение. Аудиторские UA, включая crop-audit, с блокирующего пути тоже уходят, так что тайминги проб до и после несравнимы.

Что делатьВова: либо принимаешь это как часть SEO-пачки, либо придерживаешь всю SEO-пачку. Если едет — считай экономию по полному расчётному дню продовых задержек «бот против человека» после выкатки, а не по превью: об этом сказано в самом #3568.

front#3712 влит в dev сегодня в 08:08Z: на временный сбой 429/5xx/таймаут /parts/[id] теперь рендерит ServiceUnavailable, а CDN переклеивает это краулерам в 503 + Retry-After: 300 вместо жёсткого 500. В его собственном блоке доказательств записаны три пробы по проду в 07:35Z: 500/34.9s, ответа нет/45s, 500/27.1s на CT-NHL-100016. front#3693 ЗАКРЫТ (08-20). Мои пробы четырьмя часами позже всё ещё показывают на проде 500 и ожидание 19-40s, то есть Google получает ровно то поведение, которое описано в #3693 — починка живёт только на dev, а её тикет закрыт. Сколько сегодняшних 500 приходится на аварию поиска, а сколько на что-то ещё, я разделить не могу: обе поверхности падают на одном и том же апстриме, и витрина отдаёт 500 ровно на тех запросах, которые отбивает поисковый API.

Что делатьВова: в пятницу реши, едет ли #3712 в поезде. Учти, что это эшелонированная защита — саму причину убирает подмена образа по search#924, — но только она не даст будущему всплеску 429 заново научить Google, что проиндексированные карточки отдают 500.

Оба тикета закрылись на своих мерджах в dev. Тело #3244: «замер схождения счётчиков карты сайта и карточек — это активность фазы проверки, уже после выкатки». Тело #3653: «числа „после“ завязаны на переключение переменной, поэтому приезжают с пятничным поездом, а не здесь». Проверяемое утверждение реально и конкретно — 352,201 карточка отвечает index,follow при карте сайта, заявляющей 2,378, и сходится к примерно 2,407 индексируемым URL — и я подтвердил, что прод-sitemap/1.xml по-прежнему несёт ровно те же 2,378 locs, что и до изменения. Эпик #2370 открыт, но ничего из этого не называет. То есть шаг «выкатить и проверить» для самого большого SEO-изменения в поезде не принадлежит ни одному тикету, и блок из четырёх curl-проверок в #3653 останется единственным местом, где это записано, как только PR уедет из поля зрения.

Что делатьВова: до поезда заведи один тикет (или переоткрой #3594) с четырьмя проверочными curl из #3653 и счётчиком locs в карте сайта, назначь его на себя и поставь дату после выкатки.

HEAD main в parts-services всё ещё be865716 (08-14, поезд 2026-08-13). ps#600 (cherry-pick #597, половина утечки про maxIdleTimeMS) открыт с 08-12 и не уехал 08-14; в его теле написано, что алерт открыт с 08-12T09:56Z, а user-service убивают по OOM примерно раз в сутки. ps#620 (Bun 1.3.9 -> 1.3.14, остаточная утечка TLS) влит в dev 08-17, с измеренной скоростью утечки 2.87-4.43 MiB/h по user/delivery/payment/catalog и убийствами по OOM 08-15 и 08-16; заявленная для него проверка — не тест, а прогон на dev: смотреть run.googleapis.com/container/memory/utilizations на сервисах *-dev и сравнивать наклон с этой базой. Прочитал ли кто-нибудь этот прогон — НЕДОСТУПНО: gcloud в этой сессии не авторизован (токен просрочен), и я сообщаю это как «не измерено», а не как ноль. Также в очереди с 08-11: #594 (загрузка фото падает с 500 с 06-10), #595 (документы всё ещё на Mongo), #596 (расчёт доставки застрял за записью в кэш). ps#589 открыт, так что сама утечка отслеживается; не отслеживается только то, кто и к какому сроку прочитает прогон. ps#600 ещё предупреждает: держать перезапуск ревизий наготове для user/payment/delivery/catalog, пока не приедет подъём Bun.

Что делатьВова: сделай gcloud auth login и до пятницы прочитай наклон памяти на *-dev относительно базы 2.87-4.43 MiB/h. Если ровно — выкатывай #600 вместе с подъёмом Bun и снимай перезапуск ревизий; в тот же день реши, едут ли #594/#595/#596 или выпадают из очереди.

До — продакшен сегодняHTTP 500 примерно через 17 с, тело 57,091 байт без единой позиции в списке. Ни заголовка Retry-After, ни X-Robots-Tag. Воспроизвелось на шести номерах страниц, пять из которых раньше никто не запрашивал: страница 500 (500, 17.01 с), 641 (500, 17.02 с и 17.43 с), 733 (500, 16.95 с), 852 (500, 17.14 с), 904 (500), 1000 (500, 18.63 с).

После — кандидат сегодняHTTP 200 примерно через 9-11 с, тело 54,416 байт — тоже без единой позиции в списке (рабочая страница, ?page=1, весит 483,454 байт). По-прежнему ни Retry-After, ни X-Robots-Tag. То есть клиент перестаёт получать страницу с ошибкой, но заявленный результат front#3628 — 503 + Retry-After: 300 + X-Robots-Tag: noindex для краулера — на crop-dev.app НЕ воспроизводится. Это утверждение проверяли на превью-деплое самого PR, а не на dev. Перед выкаткой стоит принять решение: человеку тихая 200 лучше, чем 500, а для Google 200 на пустой странице — это soft-404 и это хуже, чем обещанная PR 503 с Retry-After.

До — продакшен сегодняHTTP 503 за 5.44 с, retry-after: 1, cache-control: no-store, server-timing: total;dur=5003, тело {"error":"Service temporarily unavailable","message":"Search is briefly degraded — please retry.","code":"SEARCH_DEGRADED"}

После — кандидат сегодняБайт в байт то же самое: HTTP 503 за 5.49 с, retry-after: 1, total;dur=5002, то же тело SEARCH_DEGRADED. Так и задумано. Оба окружения получают от бэкенда одинаковый, корректно оформленный отказ — значит, разница между 500 и 200 в строке выше целиком в том, как витрина этот отказ обрабатывает, и ничего из этого не относится к CROP-search#874 — прод-аварии поиска.

До — продакшен сегодняТри холодных запуска (каждый раз новый ключ кэша, x-cache: MISS на всех трёх): server-timing total;dur = 3,995 мс / 1,503 мс / 2,597 мс; по часам 5.09 с / 2.51 с / 3.21 с.

После — кандидат сегодняТе же три запуска против dev: total;dur = 58 мс / 43 мс / 32 мс; по часам 1.11 с / 1.08 с / 1.05 с. По медиане примерно в 60 раз меньше времени в базе. Ответ идентичный — все шесть ответов весят 217,121 байт с md5 20eac2b35201af17324ce24b2f6d6ade — то есть в том, что видит клиент, не изменилось ничего, изменилось только время ожидания.

До — продакшен сегодняЗаголовка x-cache на этих маршрутах нет вообще, и каждый вызов доходит до PostgreSQL. Разделы: db;dur=33 и следом db;dur=39 на двух одинаковых вызовах подряд (перепроверил позже: 41 и следом 54). Узлы модели: db;dur=304 и следом db;dur=263.

После — кандидат сегодняРазделы: первый вызов db;dur=90 с x-cache: MISS, второй такой же вызов — cache;dur=0 с x-cache: HIT. Узлы модели: первый вызов db;dur=725 MISS, второй cache;dur=0 HIT. На повторе базу никто не трогает. Тела ответов в двух окружениях побайтово одинаковые (3,807 байт у разделов, 19,635 у узлов), так что это чистое снятие нагрузки с той самой базы, которая обслуживает и оформление заказа.

До — продакшен сегодняHTTP 200 за 4.02 с, server-timing search_facets;dur=3360, x-cache: MISS. Зависания на 15 секунд с 500 в конце, которое зафиксировал PR (15,082 / 16,114 / 14,360 мс на этом же ключе модели), не случилось — сегодня в 12:47Z база не перегружена.

После — кандидат сегодняHTTP 200 за 5.48 с, search_facets;dur=4762, x-cache: MISS. Новый предел в 8,000 мс не сработал ни на одной стороне, потому что ни одна к нему даже не приблизилась. Изменение, ради которого всё затевалось — быстрая 503 с Retry-After вместо 15-секундной 500, а также вместо молча пустого списка фильтров — проявляется только тогда, когда PostgreSQL перегружен, а создать это состояние я мог бы только намеренно нагрузив продовую базу, чего я не делал. Сегодня 200 с обеих сторон.

До — продакшен сегодняШесть проб между 12:44Z и 12:57Z: HTTP 200 каждый раз, 2.93 с / 3.64 с / 3.97 с / 4.12 с / 4.43 с / 6.86 с, 559,047 байт. Ошибки 500 на этом же URL, пойманные PR в 07:35Z (500 за 34.9 с, ответа нет за 45.0 с, 500 за 27.1 с), сейчас НЕ воспроизводятся — за утро продовый поиск восстановился.

После — кандидат сегодняDev отвечает 200 за 3.23 с и 3.82 с, 557,270 байт. Обе стороны здоровы, поэтому само изменение — кратковременный сбой вышестоящего сервиса доходит до клиента жёсткой 500 или же страницей «временно недоступно, попробуйте чуть позже» — прямо сейчас по требованию не наблюдается. Чтобы его увидеть, пришлось бы нагружать и без того деградировавший продовый сервис, а оба PR прямо говорят, что делать так нельзя, — я и не стал. Это единственная строка, где «до» — это утреннее измерение из PR, а не то, что встреча может перезапустить сама.

До — продакшен сегодняHTTP 307 — редирект на /sign-in?redirect_url=%2Faccount%2Fsaved-parts. Страница закрыта входом через Clerk, поэтому анонимная проба до самого поведения просто не доходит. (/garage и /saved-parts оба отдают 404 — настоящая страница это /account/saved-parts.)

После — кандидат сегодняИзмерить не удалось. Чтобы показать разницу, нужны три вещи одновременно: вошедший в аккаунт клиент, уже сохранённые у него детали и отказывающий поисковый сервис. Первые две требуют настоящей сессии, а третью нельзя безопасно создать на проде. Изменение реальное и покрыто юнит-тестами (3 из 7 тестов красные до фикса, 7 зелёных после), но снаружи пробой его не увидеть, так что на выкатку оно идёт как не проверенное end-to-end.

Эту пару сегодня наблюдать не удалось — причина в двух строках выше, и никакого числа, чтобы закрыть пробел, не выдумано.

До — продакшен сегодняНеприменимо — на проде работает образ до выкатки, в котором этого изменения нет.

После — кандидат сегодняНа dev он тоже не работает. HEAD ветки dev — 678b7af2 (search#925), но её запуск Deploy search-api-dev упал в 08:29Z с сообщением «Gate failed — candidate tag removed». Последний успешный деплой — f5518b6b (search#922) в 07:38Z, и search-api-dev до сих пор отдаёт ревизию search-api-dev-00015-yej. То есть search#925 влит, входит в завтрашний кандидат на выкатку и при этом ни разу не обслужил ни одного запроса ни в одном окружении. Всё, что измерено в строках выше, взято только из #913 + #920 + #922; ничего из этого не включает #925.

До — продакшен сегодня7 поисковых строк, которые ещё ни разу не запрашивались, на продакшене. Общее время по данным сервера: 2,137 / 15,051 / 15,173 / 15,199 / 15,272 / 15,285 / 15,454 мс — шесть из семи упёрлись ровно в 15-секундный таймаут базы, независимо от запроса. По секундомеру 4.7-17.4 с. В заголовке с таймингами на продакшене вообще нет сегмента federated_equipment, поэтому эти 15 секунд выглядят как необъяснимый провал.

После — кандидат сегодня7 новых строк на dev: 1,312 / 1,347 / 1,680 / 1,747 / 2,138 / 2,571 / 5,140 мс. По секундомеру 1.8-5.7 с. Никто не упирается в стену 15 с. В каждом ответе dev есть federated_equipment;dur=0 — у этого шага теперь свой сегмент (#896), и стоит он ноль, потому что неудачный снимок по брендам запоминается на пять минут, а не запрашивается заново (#897).

До — продакшен сегодня7 новых запросов на продакшене: 6 вернули HTTP 500 через 16.7-17.2 секунды, 1 вернул 200 через 6.2 с. Это и есть тот живой симптом для покупателя, из-за которого заведён CROP-search#924.

После — кандидат сегодня7 новых запросов на dev: 7 из 7 вернули HTTP 200, за 4.4-8.6 секунды. Оговорка прямым текстом: на dev ещё и более новый код витрины, поэтому эта строка — весь путь целиком, а не только поисковый сервис; изолированное измерение сервиса это строка 1 выше.

До — продакшен сегодняПродакшен на этих трёх маршрутах вообще не отдаёт заголовок x-cache, а db;dur= стоит в каждом вызове, включая немедленный повтор того же самого URL: сборки модели 124 и затем 139 мс, разделы 40 и затем 80 мс, карточка сборки 13 и затем 14 мс. Каждый запрос доходит до Postgres. (На /api/search и на маршрутах брендов продакшен x-cache всё-таки отдаёт, то есть заголовок не срезается — эти маршруты просто никогда не подключали.)

После — кандидат сегодняDev на первом вызове отдаёт x-cache: MISS с db;dur=, а на втором — x-cache: HIT с cache;dur=0 — и так на всех трёх маршрутах. Сознательное исключение работает как задумано: у /api/assembly-search на dev по-прежнему нет x-cache и запрос по-прежнему выполнился дважды (db;dur=970 и затем 409 мс).

До — продакшен сегодняПродакшен, общее время по данным сервера, кэш сознательно обойдён свежим nonce, 3-4 замера на модель: модель 2273 = 1,252 / 1,305 / 1,315 / 1,379 мс; модель 15661 = 1,222 / 1,229 / 1,266 мс; модель 10363 = 1,250 / 1,257 / 2,427 мс; модель 159 = 135 / 144 / 210 мс.

После — кандидат сегодняDev, те же модели, тот же метод: модель 2273 = 29 / 34 / 38 / 50 мс; модель 15661 = 85 / 99 / 100 мс; модель 10363 = 29 / 35 / 41 мс; модель 159 = 21 / 23 / 69 мс. Примерно в 30 раз быстрее на трёх крупных моделях. Ответ при этом не изменился: полный ответ модели 2273 из 916 строк побайтово совпадает на продакшене и на dev, если исключить поле с таймингом.

До — продакшен сегодня14 холодных вызовов на продакшене по самому тяжёлому шагу: 1,135 / 2,025 / 2,388 / 2,483 / 2,546 / 2,793 / 2,901 / 3,052 / 3,245 / 3,820 / 6,596 / 7,777 / 11,095 мс. Все ответили 200. Потолка нет — вызов на 11.1 секунды это продакшен, который просто ждёт, а после 15 с это превращается в 500 или в молча пустую панель.

После — кандидат сегодня16 холодных вызовов на dev, тот же шаг: от 1,497 до 7,628 мс ответили 200, а один вызов, дошедший до нового бюджета в 8 секунд, вернул HTTP 503 с Retry-After: 1 при total;dur=8061. Поймано вживую и сопоставлено с вызовом на продакшене в ту же секунду, который всё ещё ждал на 7,777 мс без всякого ограничения. Ограничение срабатывает ровно там, где заявлено в PR.

До — продакшен сегодняДефект реальный и воспроизводится сегодня. Три одинаковых запроса страницы 1 списка схем модели ABC3335398 вернули на dev-бэкенде три разные страницы — 16 и 19 строк из 50 поменяли позицию, и наборы строк были даже не одни и те же. Продакшен на те же три вызова во время проверки ответил одинаково просто потому, что сейчас у него стабильный план запроса; исправления нет ни на одной стороне, значит ни одна от этого не застрахована.

После — кандидат сегодняИзмерить нельзя. Изменение влилось в dev сегодня в 08:08Z, деплой на dev отработал, ревизия-кандидат была собрана и развёрнута без трафика, контрактный гейт не прошёл, шаг выкатки был пропущен, а ревизию-кандидат удалили. Dev отдаёт предыдущий коммит. То есть search#925 не работает ни на одном из сервисов, и если до завтра свежий деплой на dev не пройдёт свой гейт, в пятничную подмену образа он тоже не попадёт.

Эту пару сегодня измерить не удалось — причина в двух строках выше, и ни одна цифра не была придумана, чтобы закрыть пробел.

До — продакшен сегодняАдресная строка становится /parts?view=counter&pageSize=100&sortBy=name_asc&hasImage=true&categoryId=FASTENERS — каждый параметр, который там уже был, едет следом

После — кандидат на выкатку сегодняАдресная строка становится /parts?categoryId=FASTENERS — проверено сегодня на живой странице crop-dev.app, а не взято из описания PR

До — продакшен сегодняСклеенный URL отвечает <meta name="robots" content="noindex, follow"> и вообще не несёт canonical. Чистый /parts?categoryId=FASTENERS отвечает "index, follow" и указывает canonical сам на себя. То есть на проде каждый клик по категории тратил ссылочный вес на страницу, которую мы сами попросили Google выбросить.

После — кандидат на выкатку сегодняНа dev тот же склеенный URL теперь отдаёт canonical на чистый /parts?categoryId=FASTENERS. Значение robots на dev сравнить нельзя — там весь сайт намеренно отвечает "noindex, nofollow", — поэтому видимая покупателю половина этого пункта находится в строке выше: клик больше не создаёт noindex-адрес.

До — продакшен сегодня1 — полоса «таблеток» под строкой поиска висит на странице рядом со списком категорий деталей в боковой панели, отсортирована иначе и может показывать другой набор категорий

После — кандидат на выкатку сегодня0 — полосы «таблеток» больше нет; боковая панель — единственный элемент управления категориями

До — продакшен сегодня{"total":8,"toggleCounts":null} — на проде такого поля нет, поэтому страница никак не может узнать, что фильтр опустошит выдачу

После — кандидат на выкатку сегодня{"total":8,"toggleCounts":{"shipsSameDay":0,"hasImage":3}} — dev это измеряет: из 8 тормозных деталей Versatile ни одна не отгружается в день заказа

До — продакшен сегодняГалочка активна; по клику попадаем на ...&shipsSameDay=true, и страница пишет «No results match your filters»

После — кандидат на выкатку сегодняНа dev без изменений: галочка всё так же активна и всё так же приводит к «No results match your filters», хотя собственный /api/filters на dev отдаёт shipsSameDay: 0 ровно для этой комбинации. Серверная половина приехала; боковая панель в этом случае на неё не реагирует. Этот тупик выкаткой НЕ закрывается.

До — продакшен сегодня52 детали на схеме Battery: 49 показывают in_stock, 2 — call_us, 1 — непонятно. Деталь 48126818 показывает in_stock, хотя показание склада по ней RED, а страница каталога по той же детали говорит, что её нет в наличии. Кнопка «Add all in-stock» добавила бы все 49.

После — кандидат на выкатку сегодняТе же 52 детали: 34 показывают in_stock, 18 — call_us, 0 — непонятных. Деталь 48126818 теперь показывает call_us. 15 строк уходят из кнопки «Add all in-stock», и схема сходится с каталогом.

До — продакшен сегодняПрод и так показывает всё правильно в самом близком живом случае, который удалось найти: CT-AGC-302047 (онлайн-цены нет, 50 штук на нашем складе) показывает «Out of Stock» и «Ask for a price», при этом «In Stock» не встречается ни разу, и «usually ships same day» — тоже ни разу.

После — кандидат на выкатку сегодняНа dev то же самое. Мне не удалось найти ни одной живой детали в том состоянии, на которое нацелена правка: в рабочей базе каждая публикуемая деталь с ценой, но недоступная к покупке, и так показывает out_of_stock, и ни у одной из них нет остатка на складе. То есть это едет как страховка от состояния, которого сегодня ни у одной детали нет, а не как видимое исправление — пожалуйста, не описывайте это Джону как убранную живую неправду, пока кто-нибудь не найдёт такую деталь.

До — продакшен сегодняНичто не проверяло состав самой кнопки от начала до конца; поломка соответствия в снапшоте роняла всего одну не связанную с этим проверку.

После — кандидат на выкатку сегодняСнаружи наблюдать нельзя — это изменение только в тестах, у него нет ничего отрисованного на странице. И в этой сессии тест не запускался: рабочего дерева CROP-front здесь нет, а общий чекаут стоит на устаревшей ветке, так что запуск измерил бы не тот код.

Эту пару сегодня наблюдать не удалось — причина в двух строках выше, и никакая цифра не выдумана, чтобы закрыть пробел.

До — прод сегодняТупик. /parts/069526 делает один переход 308 на /parts/CT-NHL-069526, и этот адрес отвечает 404. То же самое на всех трёх проверенных строительных деталях (069526, A14858, 1014009C1) — 3 из 3 упираются в тупик, итоговый код 404.

После — кандидат сегодняРаботает. Один переход 308 на /parts/CT-NHC-069526, который отвечает 200. 3 из 3 попадают на живую страницу за один переход. У всех проверенных деталей publish_status='sellable', так что ничто другое их не скрывает.

Прод сегодняКандидат

До — прод сегодня404 сразу же, вообще без редиректа (hops=0). То же для CT-NHL-A14858 и CT-NHL-1014009C1. Каждый из этих адресов уже есть в индексе Google с прошлых обходов, и каждый — глухой тупик.

После — кандидат сегодняПереход 308 на /parts/CT-NHC-069526, который отвечает 200 (hops=1). Все три уже обойдённых адреса выводят на рабочую страницу, а не умирают.

Прод сегодняКандидат

До — прод сегодняСтраница выдаёт 6 ссылок на схемы, 6 из 6 в старом виде — с сырым кодом (например .../parts-diagrams/5FC8CAAF-B8BF-E111-9FCE-005056875BD6?highlight=21). Если по ней перейти, это 308 на .../parts-diagrams/75-200-10-spike-tooth-harrow и только потом 200 — каждая ссылка на схему стоит лишнего похода на сервер.

После — кандидат сегодняТе же 6 ссылок, 6 из 6 уже в читаемом виде (например .../parts-diagrams/75-200-10-spike-tooth-harrow?highlight=21). При переходе отвечает 200 с hops=0 — без лишнего скачка.

До — прод сегодняВозвращается 6 схем, поле assemblySlug встречается 0 раз. Витрине было не из чего строить ссылку, кроме сырого кода — именно поэтому состояние «до» в строке 3 вообще существует.

После — кандидат сегодняТе же 6 схем, assemblySlug встречается 6 раз (например "assemblySlug":"75-200-10-spike-tooth-harrow"), а отдельное поле "slug" по-прежнему несёт slug модели, без изменений. Это та половина, которая всё включает — подтверждена вживую на search-api-dev, так что front#3658 есть откуда читать настоящие данные.

До — прод сегодняСама страница открывается (200), но адрес, который она объявляет своим официальным, — https://crop.clintontractor.net/parts/CT-NHL-ESH6/L3/48 — слеш оставлен как есть и режет один номер детали на три куска пути. Если запросить этот объявленный адрес напрямую, он отвечает 404. То есть страница говорит Google, что её настоящий дом — битая ссылка.

После — кандидат сегодняТа же страница объявляет https://crop-dev.app/parts/CT-NHL-ESH6%2FL3%2F48 — слеш закодирован, адрес указывает на неё саму. Настоящий номер детали из прод PG (ESH6/L3/48, sellable, $192.91), а не выдуманный пример.

До — прод сегодняДве из трёх версий POWERSTAR-90 отдают побайтово одинаковый заголовок: 'New Holland POWERSTAR-90 ...4 B (na) - 20 chapters | CROP' — и для страницы Mechanical, и для Power Shuttle. Слова, которые их различают, обрезаны; остался только общий хвост.

После — кандидат сегодняВсе три разные: '...POWERSTAR-90 Mechanical... - 20 chapters', '...POWERSTAR-90 Power... - 20 chapters', '...POWERSTAR-90 Dual... - 20 chapters'. 3 из 3 уникальны на той же команде.

До — прод сегодняОбе страницы версий показывают один и тот же заголовок: 'New Holland POWERSTAR-90'. Покупатель, попав на любую из них, не может по заголовку понять, схемы какой версии он смотрит.

После — кандидат сегодня'New Holland POWERSTAR-90 Mechanical Tractor - Tier 4 B (na)' и 'New Holland POWERSTAR-90 Power Shuttle Tractor - Tier 4 B (na)'. Теперь заголовок несёт то, что раньше стояло только в абзаце под ним.

До — продакшен сегодняВсе три отвечают 200. CT-NHL-01111895 (нет цены, нет изображения): 200, 288,341 B, 2.19 s. CT-NHL-0145155 (нет данных CNH): 200, 338,531 B, 2.93 s. CT-NHL-100074 (контрольная — снятая с продажи деталь, у которой изображение есть): 200, 289,938 B, 2.34 s. Продакшен-база PG, запрос напрямую сегодня: у 75,048 строк нет данных CNH, ещё 332,254 сняты с продажи и не имеют ни цены, ни изображения — 407,302 URL такого вида.

После — кандидат сегодняДве мёртвые отвечают 404 объёмом 101,413 B за 0.51 s каждая — треть секунды вместо двух с половиной и треть байтов. Контрольная не тронута: 200, 285,347 B — те 13,626 снятых с продажи деталей, у которых всё ещё есть цена или изображение, свою страницу сохраняют.

Продакшен сегодняКандидат

До — продакшен сегодня404 на продакшене отдаётся с cdn-cache-control: public, s-maxage=3600, stale-while-revalidate=86400 и cache-control: s-maxage=31536000 — час свежий, потом ещё сутки отдаётся устаревшим. Доступность детали к покупке пересчитывается ночью, поэтому вернувшаяся деталь могла продолжать отвечать 404 до двадцати пяти часов.

После — кандидат сегодня404 на dev отдаётся с cdn-cache-control: public, s-maxage=300 без stale-while-revalidate и с cache-control: public, max-age=0, must-revalidate. Подтверждено и на реальной снятой с продажи детали: /parts/CT-NHL-20348S отвечает на dev 404 с s-maxage=300 и x-vercel-cache: HIT при age 184.

До — продакшен сегодняНа продакшене все три мёртвых URL отвечают 200 браузеру и 404 для Googlebot. /brand/zzz-not-a-brand, /parts-diagrams/new-holland/ZZZ-NOT-A-MODEL и /parts-diagrams/mchale/ZZZ-NOT-A-MODEL/ZZZ-NOT-AN-ASM: chrome=200, googlebot=404 у каждого. Живая контрольная /brand/new-holland-agriculture отвечает 200 обоим.

После — кандидат сегодняНа dev все три отвечают 404 обоим. Живая контрольная по-прежнему отвечает 200 обоим. Статус больше не зависит от того, кто спрашивает.

Продакшен сегодняКандидат

До — продакшен сегодняНа продакшене Googlebot получает x-vercel-cache: BYPASS на /parts/CT-NHL-100016 — дважды подряд, 2.67 s и 4.68 s. Браузер, который в ту же минуту запрашивает тот же самый URL, получает x-vercel-cache: HIT. Каждый обход оплачивал свежий рендер, который никто не сохранял.

После — кандидат сегодняНа dev Googlebot получает x-vercel-cache: HIT — то же состояние кеша, что и браузер, на том же URL. Как выигрыш по времени это здесь не измеряется: dev — другой, более холодный деплой, поэтому секунды тут шум. Факт — это состояние кеша.

До — продакшен сегодняПродакшен отдаёт три индексируемые ссылки, которые тащат параметры отображения дальше: /parts?view=counter&pageSize=100&page=2, &page=3 и &page=1000. Отдельно: /parts?view=grid отдаёт index, follow с canonical, указывающим на /parts, а /parts?pageSize=100 — такой же по сути параметр на той же странице — отдаёт noindex, follow вообще без canonical.

После — кандидат сегодняDev отдаёт /parts?page=2, /parts?page=3 и /parts?page=1000 — параметры отображения из ссылок исчезли. Ту половину изменения, которая про тег robots, на dev отделить нельзя: dev по настройке окружения отдаёт noindex, nofollow на каждой странице и выдаёт canonical даже на /parts?pageSize=100 — там, где правило продакшена его убирает. До пятницы чисто измеримы только ссылки.

До — продакшен сегодняНа продакшене /parts/brand/new-holland-agriculture/type/balers?page=7 отвечает index, follow и называет своим canonical https://crop.clintontractor.net/parts/brand/new-holland-agriculture/type/balers — первую страницу, у которой нет ни одной детали с седьмой. /parts/brand/new-holland-agriculture?page=7 отвечает index, follow с заголовком New Holland Parts | Clinton Tractor — Page 7.

После — кандидат сегодняНа dev страница пресс-подборщиков называет своим canonical саму себя: .../type/balers?page=7. Заголовок бренда читается как New Holland Parts — Page 7 | Clinton Tractor: номер страницы перед названием магазина, как на /parts. Третью часть этого изменения — глубокие страницы бренда отвечают noindex после пятой — на dev прочитать нельзя, потому что dev в любом случае отвечает noindex на каждой странице.

Продакшен сегодняКандидат

До — продакшен сегодняИзмерено сегодня на продакшене. Sitemap заявляет 18,657 URL (16,279 + 2,378), и 16,250 из них — 87 процентов — это дерево техники по моделям и его хабы схем. Только 2,378 из них — товарные страницы. При этом /parts/CT-NHL-219758, которого в sitemap нет вообще, отвечает 200 с index, follow, и то же самое делают /equipment/attachments-rotary-broom-aad86496ef и его хаб /parts-diagrams. В продакшен-базе PG 579,518 строк деталей помечены как публикуемые — против тех самых 2,378 заявленных: тег robots и sitemap живут по двум разным правилам.

После — кандидат сегодняНа dev наблюдать нельзя, да и не было бы видно, даже если бы было можно. Три отдельные причины, каждая проверена: robots.txt на dev — это User-Agent: * / Disallow: /, и каждая страница по настройке окружения отвечает noindex, nofollow, так что ни один тег robots не отличить; /sitemap.xml, /sitemap-index.xml, /sitemap/0.xml, /sitemap/1.xml и /sitemap-images/0.xml на dev отвечают 404 — считать попросту нечего; и оба переключателя, которые добавляет этот PR, по замыслу поставляются выключенными, так что изменение бездействует, пока после выкатки в продакшене не выставят значения окружения. Цифра 2,407 URL в PR — это прогноз, а не измерение.

Эту пару сегодня наблюдать не удалось — причина в двух строках выше, и никакая цифра не выдумана, чтобы закрыть пробел.

До — продакшен сегодняПродакшен отвечает 500 на обеих, без Retry-After и без заголовка noindex: /parts?page=500 за 17.0 s и /parts/brand/new-holland-agriculture?page=300 за 19.3 s. Именно повторяющиеся 500 говорят Google обходить сайт реже.

После — кандидат сегодняНа dev наблюдать нельзя. Dev отвечает 200 на обоих этих URL — 11.6 s и 14.9 s — пустым списком без единой ссылки на товар, потому что поисковый сервис на dev не отказывает глубокой странице так, как это делает продакшен. Изменение всего лишь переобозначает страницу, которая упала, а на dev ничего не падает — значит, и переобозначать нечего. Поиск на продакшене сегодня к тому же деградировал (CROP-search#924, выкатка стоит в очереди), а это значит, что даже на стороне продакшена я не могу отделить задуманный отказ на глубокой странице от этой аварии.

Эту пару сегодня наблюдать не удалось — причина в двух строках выше, и никакая цифра не выдумана, чтобы закрыть пробел.

До — продакшен сегодня{"total":2681,"batchSize":5000,"boundaries":[]} — 2,681 товар проходит в фид, одним файлом. Всё ограничивал фильтр clinton_on_hand > 0, то есть рекламировать можно было только те детали, которые физически лежат на собственном складе Clinton.

После — кандидат сегодня{"total":97619,"batchSize":25000,"boundaries":["NHL|47886103","NHL|84071622","NHL|87419908"]} — 97,619 товаров в 4 файлах по 25,000. Это в 36 раз больше товаров и 4 источника данных в Merchant Center вместо 20.

До — продакшен сегодняПродакшен выдаёт URL фотографии без префикса бакета parts/ — https://media.clintontractor.net/ct/bns/1650347SM/gallery/1650347SM-1.jpg. Такой вид у 405 из 2,681 строк на проде, и 10 из 10 проверенных отдают 404.

После — кандидат сегодняDev выдаёт https://media.clintontractor.net/parts/ct/bns/1650347SM/gallery/1650347SM-1.jpg, и 10 из 10 проверенных отдают 200. Та же фотография, та же деталь: URL с прода отдаёт 404 там, где dev-URL рядом отдаёт 200 в том же прогоне.

До — продакшен сегодняЖивой фид подставляет миниатюру из каталога CNH у 2,278 из 2,632 позиций (86%). Все 12 из 12 проверенных ровно 510x287 — 0 из 12 проходят порог Merchant Center 500x500 по размеру, то есть такие позиции будут отклонены. Аудит в ops оценил то же самое как 4 из 24.

После — кандидат сегодняСтроки merchant, которые читает новый фид, несут вместо неё фотографию из галереи: 12 из 12 проверенных >=500x500 (обычно 1024x1024 и одна 1612x1209), и у 25,000 из 25,000 строк фотография вообще есть. Честная оговорка: это измерено на источнике, который читает новый фид, а не на самом файле фида, потому что /feed/google/*.xml отдаёт 404 вне продакшена. Собственный g:image_link фида можно будет измерить только после пятничной выкатки.

До — продакшен сегодняИзмерено на проде сегодня: 1 шард, 2,632 позиции (шарды 1-3 отдают 404). Критерий аудита 1 НЕ ПРОЙДЕН — 0 из 2,632 g:id несут канонический SKU вида CT-VENDOR-PN; там голые номера деталей вроде 1650347SM, то есть Merchant Center привяжет статистику по товарам к идентификатору, который мы вот-вот поменяем. g:google_product_category равен 888 (голый корень Vehicles & Parts) у всех 2,632 позиций; g:product_type — у 0 позиций; g:shipping — у 2,256 (85%), фиксированные 9.00 USD, которые противоречат правилу «бесплатно от $75»; g:description побайтово совпадает с заголовком у 2,306 (87%). Критерии 2 и 4 сегодня проходят: ссылки 40/40 отдают 200 без редиректа, совпадение 20/20 фид == JSON-LD карточки детали.

После — кандидат сегодняИЗМЕРИТЬ НЕ УДАЛОСЬ. /feed/google/0.xml и далее до 3.xml — все отдают 404 на crop-dev.app: вне продакшена маршрут намеренно закрывается по IS_INDEXING_ENABLED, так что 404 здесь — правильное поведение, а не поломка. Прогон аудита с --base https://crop-dev.app показывает 0 шардов / 0 позиций именно поэтому, а не потому, что фид пустой. Этот 404 — настоящий 404 и не стена входа Vercel: тот же заголовок обхода на /parts/CT-FER-1608395 отдаёт 200 при итоговом URL всё том же crop-dev.app. Первое наблюдаемое «после» — та же команда аудита, прогнанная по проду после пятничной выкатки.

Эту пару сегодня наблюдать не удалось — причина в двух строках выше, и никакого числа, чтобы закрыть пробел, не выдумано.

До — продакшен сегодняПрод. Из 12 проверенных страниц деталей 9 сообщают Google наличие, а 3 вообще не отдают availability внутри Offer — CT-AGC-000-1158, CT-AGC-000-1182, CT-FER-1608395. У CT-AGC-000-1158 в её же серверном HTML отрисован бейдж "Out of Stock", а Google при этом не сообщается вообще ничего. У CT-FER-1608395: name = "Spring-Extn 1.040ODX 04.000LG .105WIRE D... 1608395" (буквальное многоточие из-за обрезки в 70 символов, с приклеенным номером детали); description = "Genuine Ferris spring-extn, part 1608395. $13.99 at Clinton Tractor." (цена лежит внутри описания товара, поэтому устаревает); category = "Ferris" — это бренд, а не категория; itemCondition стоит на Product; seller — анонимная Organization; @id нет ни у одного узла.

После — кандидат сегодняDev. 12 из 12 проверенных страниц отдают availability. Те три, что прод пропускал, читаются как OutOfStock / OutOfStock / InStock, и у CT-AGC-000-1158 JSON-LD и отрисованный сервером бейдж теперь говорят одно и то же — оба Out of Stock. У CT-FER-1608395: name = "Spring-Extn 1.040ODX 04.000LG .105WIRE D" (без многоточия и без приклеенного номера детали); description = "Genuine Ferris spring-extn, part 1608395." — цена ушла; category не ошибочная, а просто отсутствует; itemCondition переехал в Offer; у seller есть @id .../#org, а у Product — @id .../#product, так что Google сводит всё к одному продавцу вместо анонимного.

До — продакшен сегодняprod {"numberOfItems":40,"entries":40,"priced":40,"pricesVisibleInHtml":18,"entriesWithImage":0} — Google сообщают 40 цен, а найти в собственном HTML страницы можно только 18 из них (18 — это ровно бюджет немедленного рендера; остальные 22 карточки уходят заглушкой без цены). Ни одна из 40 записей не несёт картинку. Размеченный контент, которого не видно на странице, — это нарушение правил Google по структурированным данным, и применяют его сразу ко всему сайту, а не к отдельному URL.

После — кандидат сегодняdev {"numberOfItems":40,"entries":40,"priced":40,"pricesVisibleInHtml":40,"entriesWithImage":40} — все 40 размеченных цен присутствуют в HTML страницы вне скриптов, и все 40 записей несут картинку.

До — продакшен сегодняprod: 516,737 байт, 64 ссылки /parts/ на 16 уникальных деталей — ссылка каждой детали отдаётся четыре раза, потому что всё поддерево спецификации рендерилось дважды (по разу на брейкпоинт), а каждая строка сверху складывала вторую копию ссылки на свой номер детали.

После — кандидат сегодняdev: 360,590 байт (-30.2%), 16 ссылок /parts/ на те же 16 уникальных деталей. Число уникальных ссылок с обеих сторон одинаково, то есть ни одна ссылка не потерялась — ушли только дубли. Выигрыш растёт вместе с числом строк в схеме; здесь страница на 16 строк.

До — продакшен сегодняorigin/main (то, из чего собран продакшен) отвечает: REJECT: International addresses are not supported. We currently ship to US only. Американская улица, названная в честь страны, ломается точно так же — '456 Mexico St, Springfield, IL 62701' тоже отклоняется. Если ввести 'NM' — работает; если вставить полный адрес — нет.

После — кандидат сегодняorigin/dev отвечает: OK state=NM. '456 Mexico St, Springfield, IL 62701' -> OK state=IL. Настоящий международный адрес по-прежнему отклоняется: 'Calle Reforma 100, Mexico City, DF 01000' -> REJECT: International addresses are not supported.

До — продакшен сегодняБандл, который отдаёт продакшен: replace(/\s+/g," ");if(t=s,[/\b(?:canada|uk|united — проверка на страну стоит ПЕРВЫМ выражением в разборе адреса, поэтому она срабатывает до того, как начнётся сам разбор, и 'New Mexico' попадает под слово 'mexico'.

После — кандидат сегодняБандл, который отдаёт dev: ngs:s})}(t,i,a);return l?l:[/\b(?:canada|uk|united — та же проверка на страну теперь выполняется только после того, как стратегии разбора ничего не вернули. Проверено, что запрос к dev остался на crop-dev.app (url_effective=https://crop-dev.app/checkout/shipping, http=200), а не ушёл на страницу входа Vercel.

До — продакшен сегодняorigin/main: 0 — маршрут Express Checkout не проверяет цену вообще. Живой payment-service последний раз выкатывали 2026-08-14 из main@be865716, значит именно это работает в продакшене сегодня: unitPrice, присланный самим браузером, уходит в Stripe без проверки, тогда как обычная страница оформления заказа (hosted Checkout) ровно ту же корзину отклоняет.

После — кандидат сегодняorigin/dev: 2 упоминания — та же защита, которой пользуется обычная страница оформления заказа. Dev-овский payment-service выкатили 2026-08-18 из dev@d626f353, и в нём исправление есть (проверено через git merge-base --is-ancestor). В рантайме намеренно НЕ проверяли: чтобы воспроизвести «до», пришлось бы подделать корзину и дёрнуть POST /payment-intent, а на продакшене это создаёт настоящий PaymentIntent в боевом режиме. Сознательно не стали.

До — продакшен сегодняorigin/main: 0. Ни один тест в платёжном сервисе не смотрит, с чем вызывается orderRepo.create — все наборы тестов по вебхукам проверяли только сам факт вызова. Налог, доставку, скидку, итог, валюту и цены за единицу в каждой строке можно было переписать в любом оплаченном заказе, а сборка осталась бы зелёной.

После — кандидат сегодняorigin/dev: 1 набор тестов, 7 кейсов, 17 буквальных expect( в файле (в PR указан 21 вызов проверки, когда набор запускает bun) — покрыты оба пути записи заказа: обычная страница Checkout и Express Checkout. В этот заход я набор не запускал: ему нужен свежий worktree и полный bun install, поэтому строка измеряет код, который есть, а не зелёный прогон.

До — продакшен сегодняorigin/main, строка 188: cost: Number.parseFloat(total.MonetaryValue ?? '0') — тариф без цены превращается ровно в 0.00 и показывается покупателю как настоящий бесплатный вариант, который можно выбрать, а реальный счёт перевозчика остаётся на нас. Продакшеновский delivery-service выкатили 2026-08-14 из main@be865716, так что это живёт в продакшене сегодня.

После — кандидат сегодняorigin/dev, строка 178: Number.parseFloat(total.MonetaryValue ?? '') плюс отбрасывание с предупреждением, если значение не конечное число больше нуля; если отброшены все тарифы, расчёт падает, а не уходит в бесплатный. Dev-овский delivery-service выкатили 2026-08-18 из dev@38352042, и это И ЕСТЬ merge-коммит #624 — сам симптом снаружи не спровоцировать: только UPS решает, когда ответить без блока со стоимостью, — поэтому «до» вживую не воспроизводили, и вся гарантия держится на 9 новых тестах (6 из них падали до исправления).

До — продакшен сегодняПродакшен возвращает 5 вариантов за 1.1s: Clinton Tractor In-Store Pickup $0, Clinton Tractor FREE shipping $0, UPS Ground $14.02, UPS 2nd Day Air $33.57, UPS Next Day Air $53.93.

После — кандидат сегодняDev возвращает те же 5 вариантов по тем же ценам за 1.5s. Это защита от перегиба: наши собственные два намеренных тарифа по $0.00 (самовывоз и бесплатная доставка) остались нетронутыми, потому что новая проверка живёт только внутри провайдера UPS, а все тарифы UPS по-прежнему возвращаются с ценой.

До — продакшен сегодняПродакшен отвечает ready=true gitSha=be865716b8f668d3245e4595b82d3377cd1e5133 — он называет собственную сборку, и этот коммит — HEAD origin/main от 2026-08-14.

После — кандидат сегодняDev отвечает ready=true gitSha=unknown. Dev-овский workflow деплоя вообще не передаёт сборочный аргумент GIT_SHA (его передаёт только delivery-deploy.yml, в строке 103), поэтому dev-сервис не может назвать себя, и его сборку приходится брать из записи о деплое в GitHub Actions. Стоит починить: проверка в день выкатки, идущая по dev, не может сама подтвердить, что именно она только что проверила.