15 commits

Author	SHA1	Message	Date
bot-backend	d177b916e3	fix(caddy): страница «сервис обновляется» вместо голого 502 в окне деплоя ... Каждый мерж в tradein оставляет 30-90 с, в которые контейнера нет и Caddy набирает несуществующий апстрим: 15 x 502 на meraocenka.ru и 23 на gendsgn.ru за 4 суток, все на окнах деплоя (duration < 2 мс = мгновенный отказ соединения, а не перегрузка). handle_errors 502/503/504 подменяет это на 503 + Retry-After: 30 и читаемое тело. 502 читается как постоянная поломка — поисковик выкидывает страницу из индекса, клиенты не ретраят; 503 + Retry-After означает ровно то, что происходит. Для /trade-in/api/* тело JSON, а не HTML: эти ручки вызывают из JS и внешних клиентов, HTML у них превращается в ошибку разбора. На gendsgn.ru перехват гейтится по пути /trade-in* — Site Finder («Птица») деплоится отдельным пайплайном и в задачу не входит; вне матчера ошибка остаётся необработанной и поведение прежнее. Окно простоя это НЕ убирает — zero-downtime деплой (п.1 issue) требует решения владельца. Меняется только то, что видно внутри окна. Refs #3274	2026-09-05 22:48:54 +05:00
bot-backend	5d9ff13dae	fix(caddy): исключить _not-found из фильтра чанков закрытого контура ... Ревью #3340: `chunks/app/_not-found/` — внутренняя страница Next, а не маршрут продукта; фильтр её глушил, и клиентская навигация по битому href падала в error-boundary вместо честного «не найдено». Закрытого кода она не несёт. Заодно в комментарии матчера явно зафиксировано, что `static/css/app/<маршрут>/*` оставлен без фильтра сознательно — тот же класс «имена, а не код», потолок уже задекларирован.	2026-09-02 17:47:28 +05:00
bot-backend	177207223b	fix(caddy): снять мёртвый internal-секрет с анонимного пути и чанки закрытого контура с публичного домена ... #3324, п.3: Caddy на gendsgn.ru инжектил X-Internal-Auth-Secret в каждый анонимный запрос /trade-in/api/* и /trade-in/* (хоп во фронт). Сравнение недостижимо по построению: backend читает этот заголовок только в legacy trusted-header ветке rbac.py, и только после непустого X-Authenticated-User, который тот же самый хоп строкой ниже удаляет. Второй потребитель секрета (вебхук GlitchTip) берёт его из query-параметра. Защита от подделки заголовков внутри gendesign_shared — проверка в rbac.py, она не тронута; инжект работал в обратную сторону, раздавая секрет наружу. #3324, п.1: meraocenka.ru раздавал анонимам постраничные чанки App Router чужих маршрутов (chunks/app/{admin,team,scrapers,...}/) — код закрытого контура с именами внутренних ручек. Матчер отсекает 404-ом «есть подкаталог, и он не mera-public»; лэндингу нужны только chunks/app/<файл>.js и chunks/app/mera-public/* (замер на проде). Карта чанков в webpack-*.js остаётся — имена файлов по-прежнему читаются, полное разделение = split build. Регресс-тесты в smoke-mera-perimeter.sh отличают 404 Caddy (пустое тело) от 404 Next и отдельно проверяют, что статика лэндинга жива.	2026-09-02 17:41:38 +05:00
bot-backend	4d51d19f7c	feat(mera-public): публичная страница /business вместо ссылки на форму входа ... Кнопка «Для бизнеса» в шапке и «МЕРА для бизнеса» в подвале вели на B2B_URL. Реальная цепочка на проде: 308 → /trade-in → 307 → /trade-in/v2 → клиентский редирект → /trade-in/login. Посетитель публичного сайта упирался в форму «Логин / Пароль» от аккаунта, которого у него нет. Заведена страница /business: кому полезен бизнес-контур, чем он отличается от бесплатной проверки, и как связаться (почта и телеграм — те же константы, что в подвале и в документах, не выдуманные для страницы). Ни цен, ни сроков, ни объёмов: этих величин никто не мерил. Ссылка на вход оставлена внутри страницы второстепенной — «уже работаете с нами». Периметр согласован во всех четырёх местах: PUBLIC_ROUTES, три матчера Caddy (@meraPages, @meraShortSlash, @meraLongPages), PUBLIC_SHORT_PATHS в RouteGuard, плюс строка в smoke-mera-perimeter.sh. Гейт периметра проверен фальсификацией: удаление /business из @meraShortSlash роняет public-perimeter.test.ts. noindex — тем же способом, что у /docs (metadata.robots). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-31 12:40:59 +05:00
bot-backend	49652f4413	fix(mera/b2c): вернуть потерянные вопросы FAQ, починить адрес превью и честность двух комментариев ... Правки по трём ревью ветки «v3 становится корнем». FAQ. Из шести вопросов `content.ts` возражения v3 брали два, остальные четыре (`how-accurate`, `vs-marketplace`, `personal-data`, `bank-report`) не рендерились нигде: `Faq.tsx`, который выводил все шесть, удалён вместе с лэндингом v1. Макетные возражения их тематически закрывали, но пересказом — а оригиналы проходили юр-ревью. Содержательно пропали два утверждения: «Имя, паспорт и документы на квартиру мы не спрашиваем» с отсылкой к странице ПДн (152-ФЗ) и «показываем диапазон, а не одно число» как прямой ответ про точность (рамка диапазона осталась только в `AccuracyV3`, рядом с плейсхолдерными числами). Теперь в секции один порядок чтения: все шесть вопросов из `FAQ` по id плюс три макетных возражения, которым в `FAQ` пары нет («факт сделки», «почему так дёшево», «подписка»). Три макетных пересказа удалены в пользу оригиналов; у «почему так дёшево» убран второй абзац — почти дословный повтор второго абзаца `how-accurate`, который теперь стоит следующим. Новых формулировок не добавлено. Отсылка к странице ПДн стала живой ссылкой через `PublicLink` (обычный `<a>`, basePath не течёт); текст ссылки — слова самого `content.ts`, найденные по вхождению. Гейт стал двусторонним: тест перебирает `FAQ` и требует, чтобы КАЖДЫЙ id был отрисован. Прежняя версия перечисляла два id руками и потому молчала ровно в тот момент, когда четыре ответа исчезли со страницы. Проверено мутацией: снятие вопроса, переименование id и переформулировка фразы про ПДн красят тест по отдельности. CADDY. `/trade-in/mera-public/v3` выбыл из @meraLongPages вместе со страницей и никуда не попал — длинный адрес превью падал в catch-all 404, хотя раньше вёл на страницу. Обе его формы добавлены в @meraV3Gone. Там же редирект перестал терять query: было `redir * /`, стало `redir * {uri}` со срезанием пути — как у @meraLongPages, где перенос UTM и обоснован. Проверено на живом Caddy 2.11 по настоящему site-блоку: все четыре формы дают 301 на `/` с сохранённой query, без параметров — чистый `/` без хвоста `?`, соседние матчеры не задеты, лишний сегмент по-прежнему 404. КОММЕНТАРИИ, ОПИСЫВАЮЩИЕ НЕСУЩЕСТВУЮЩЕЕ. Строка `page.tsx` в гейте плейсхолдеров убрана: комментарий над ней утверждал, что устаревший путь «перестал бы что-либо сканировать», но ни в корневом `page.tsx`, ни в прежнем `v3/page.tsx` нет ни одного имени из `PLACEHOLDER_EXPORTS` — страница только собирает секции. Замер подтверждает: множество найденных плейсхолдеров со строкой и без неё совпадает, а сама по себе она не даёт ничего. Держать её значило держать ложное ощущение охвата. Дескриптор «Оценка вторичного жилья по рыночным данным · <регион>» на внутренние страницы не возвращается — причина записана в докстринге `InnerHeader`: эту шапку носят и `/estimate`, `/articles`, `/docs`, где дескриптора не было никогда; требование юриста было про первый экран лэндинга и там выполняется `HeroV3`; на самих юр-страницах то же сказано сильнее — в тексте оферты (п. 1.3, 6.2) и в `FooterV3` на каждой странице.	2026-08-29 19:35:57 +05:00
bot-backend	6976ca8915	feat(mera/b2c): лэндинг v3 становится корнем публичного домена ... Вариант дизайна выбран — превью с /mera-public/v3 переехало в корень целиком, вместе с блоками, перенесёнными из v1 предыдущим шагом. Каталог v3/ и компоненты v1 (Hero / HowItWorks / WhatYouGet / DataSources / Faq / AddressForm / SiteHeader / SiteFooter) удалены: их данные живут в content.ts и уже читаются секциями v3, поэтому ушла только вёрстка. Юридические страницы (оферта, возврат, ПДн) держались на SiteHeader/ SiteFooter — единственные, кто их ещё импортировал. Переведены на InnerHeader + FooterV3, тем же способом, что /estimate, /articles и /docs. ПЕРИМЕТР. /v3 убран из @meraPages, @meraShortSlash и @meraLongPages, но не выброшен: адрес две недели был открыт наружу и разошёлся по закладкам, поэтому вместо тишины белого списка — 301 на корень (@meraV3Gone, обе формы). На это заведена проверка в public-perimeter.test.ts по образцу соседних; PREVIEW_ONLY стал пустым, а не удалённым — он держит проверку «наружу не открыто ничего сверх известных страниц» двусторонней. Из PUBLIC_SHORT_PATHS гварда /v3 убран: редирект отрабатывает в Caddy, до приложения запрос не доходит, а недостижимая строка в списке публичных путей сделала бы публичной будущую страницу с тем же адресом. Гейт Caddy→гвард односторонний и сам бы этого не поймал — обоснование в коде. NOINDEX ОСТАВЛЕН. Он держится за плейсхолдерные числа marketing-v3.ts (#2904), а не за то, какой вариант дизайна стоит в корне. Путь в гейте обновлён на page.tsx: placeholdersInUse() молча пропускает ненайденный файл, поэтому устаревшая строка не покраснела бы, а перестала бы сканировать.	2026-08-29 18:59:43 +05:00
bot-backend	2d8edd2c4f	feat(mera/b2c): раздел статей и хаб документов (макет 29.08) + числа статьи заменены на замер ... Последняя часть макета Макса «B2C модуль для МЕРА»: /articles, /articles/kak-ocenit-kvartiru, /docs. Проводка ссылок доведена до конца — «Статьи» и «Проверьте себя» в шапке и подвале перестали быть заглушками, EstimateHeader переименован в InnerHeader (он теперь стоит на трёх страницах, а не только на проверке). ЧИСЛА СТАТЬИ — НЕ ИЗ МАКЕТА. Макет утверждал «по нашим данным, средний разрыв между первой ценой в объявлении и ценой сделки — 4,1%, а у провисевших дольше трёх месяцев доходит до 9%». Прод-замер (poincare, 29.08) показал, что величины такого рода у нас нет вовсе: связки листинга со сделкой в данных не существует (cadastral_number пуст у всех 108 623 сделок и 111 693 объявлений). Заменено на то, что измеряется парно и честно: по 6202 объявлениям Домклик в ЕКБ (срез 18.07.2026) цену снижали 44%, а среди провисевших дольше трёх месяцев — 62% в медиане на 4,9%. Границы замера названы в самом тексте: это движение цены В ОБЪЯВЛЕНИИ, а не скидка на сделке, и объявлений моложе трёх недель в выборке нет (прогон обогащения их не захватил), поэтому по всему живому рынку доля ниже. Заодно сняты остальные непроверяемые утверждения: «расхождение с кадастровой до 40%» (кадастровой стоимости ПОМЕЩЕНИЙ нет ни в одной базе — проверить нечем), поправки §3 помечены как рыночная практика, а не наш замер, пороги фильтра §2 приведены к тем, что реально стоят в оценщике (радиус 1 км, площадь ±15%, минимум 5 аналогов + каскад послаблений). Плейсхолдеров marketing-v3 в статье не осталось. Периметр закрыт во всех трёх местах: @meraPages / @meraShortSlash / @meraLongPages в apps.caddy, PUBLIC_ROUTES и PUBLIC_SHORT_PATHS в гварде. @meraShortSlash до сих пор не проверялся ничем — добавлен гейт в public-perimeter.test.ts (фальсифицирован: снятие /docs из альтернации красит тест). Гейт #2904 теперь видит и статью (articles-content.ts в V3_SOURCES) — фальсифицировано отдельно: с одним этим файлом в списке снятие noindex красит гейт. Честные отличия от макета — в докстрингах страниц: масок реквизитов и макетной редакции оферты нет (источник правды — /oferta, /privacy, /refund от 13.08), регламент ответа поддержки «9:00-19:00» снят (никто его не устанавливал), фильтр рубрик и обещание «новые статьи каждую неделю» не рендерятся. Проверено: tsc, eslint, vitest 69/69, изоляция mera-public, скриншоты трёх страниц на 1180/375/320px без горизонтального переполнения.	2026-08-29 17:53:44 +05:00
lekss361	d0547ddb9a	Merge pull request 'feat(observability): кнопка «Принял в работу» под клиентским инцидентом (#3078)' (#3136) from feat/3078-alert-ack-button into main	2026-08-27 11:58:41 +00:00
bot-backend	031b4559b9	fix(mera/perimeter): www-формы доменов МЕРА обрывали TLS вместо редиректа ... A-записи www.meraocenka.ru / www.merahome.ru / www.meraotsenka.ru заведены и указывают на прод, но site-блоков под них в Caddy не было. Caddy матчит строго по имени хоста и на неизвестное имя сертификата не выпускает, поэтому клиент, набравший привычное «www.», получал обрыв рукопожатия (TLS alert 80) — для браузера это «сайт не открывается». В логах доступа при этом ни строки: до HTTP-слоя запрос не доходил, так что молчали и метрики. www.gendsgn.ru такой блок имел с самого начала и потому работал — здесь ровно тот же приём, три отдельных блока с 301 на канонический meraocenka.ru. Найдено сквозным аудитом периметра 27.08. Проверено: три www-имени резолвятся в 188.124.37.140, curl до правки возвращал пустой код (000) на всех трёх, www.gendsgn.ru — 301. Смоук периметра дополнен проверкой 5b: отсутствие блока проявляется НЕ как 404, а как пустой код ответа, и обычная проверка «спутники отдают 301» такой регресс не ловила.	2026-08-27 14:17:15 +03:00
bot-backend	053a5fb75c	feat(observability): кнопка «Принял в работу» под клиентским инцидентом (#3078) ... Alertmanager инлайн-клавиатуру не поддерживает, а без кнопки нет обратной связи «человек увидел и взял в работу»: 27.08 продукты лежали 10 часов, и вопрос «а кто-нибудь это читает» было не к кому адресовать. ГДЕ ЖИВЁТ. Рядом с Alertmanager, на инфраструктурной машине. У бота МЕРЫ уже есть приём обновлений, и повесить обработку туда было бы дешевле, но он работает на продуктовом хосте: при падении продукта кнопка оказалась бы мёртвой ровно тогда, когда нужна. ССЫЛКА, А НЕ CALLBACK. Callback требует читателя обновлений бота. Бот один, и его обновления уже читает МЕРА — второй читатель получил бы 409 Conflict и отобрал бы сообщения у поддержки. БЕЗ ПАРОЛЯ НА /ack/*, ОСОЗНАННО. Кнопку жмут ночью с телефона, когда лежит прод; требование пароля даст ноль нажатий. Защита — 128-битный токен под конкретное сообщение, живущий сутки; максимум, чего добьётся угадавший, — ложная отметка в чате, где сразу видно, что её поставил не человек. ТОЛЬКО КЛИЕНТСКИЙ МАРШРУТ идёт через сервис. Прочие алерты сохраняют прямой путь в Telegram: чем меньше звеньев, тем надёжнее. Если сервис лёг, Alertmanager повторяет доставку и переуведомляет каждые 30 минут — алерт задерживается, но не теряется. Дублировать вторым прямым каналом не стали: шум в канале тревог опаснее задержки. Девять тестов дёргают настоящие функции, подменяя один шов — вызов Bot API. Важнейший: при отказе отправки с клавиатурой сообщение уходит БЕЗ неё — алерт важнее кнопки.	2026-08-27 13:56:00 +03:00
bot-backend	efaab2efda	chore(ops): адрес Poincare — 188.124.37.140 вместо заменённого 188.246.224.93 (#3110) ... Selectel заменил адрес сервера в ночь на 27.08 по нашей заявке: старый 188.246.224.93 фильтровался российскими операторами и не открывался ни с домашнего интернета, ни с мобильного (#3110). Новый адрес фильтрации не имеет — проверено с машины владельца после переключения DNS. Замена уронила сервер на 10 часов: адрес на порте сменился, а в ОС остался прежний (разбор и восстановление — #3119). Здесь только то, что осталось в репозитории. Единственное функциональное вхождение — дефолт HOST_IP в ops/selectel-ci-access.sh: скрипт открывает раннеру доступ на прод-хост, и с прежним значением он молча настроил бы доступ на адрес, которого у нас больше нет. Остальные семь — тексты комментариев в Caddyfile-секциях, compose, bootstrap-скриптах и раннбуке крона; они не исполняются, но именно по ним сверяются при переезде, и разошедшийся адрес в них дороже, чем кажется.	2026-08-27 11:23:37 +03:00
bot-backend	f893662ef1	fix(observability): у Grafana остаётся один вход (#3078) ... Внешний basic_auth Caddy снят с витрины по решению владельца: два запроса пароля подряд мешали работе, а у Grafana есть собственная аутентификация с ролями и GF_USERS_ALLOW_SIGN_UP=false. Что теряется, чтобы решение было осознанным: basic_auth отсекал сканеры до Grafana и прикрыл бы её собственную будущую уязвимость. Теперь страница входа видна из интернета напрямую. Это записано комментарием прямо в конфиге, чтобы через полгода не выглядело недосмотром. Приём метрик НАРОЧНО остаётся под basic_auth: туда ходит агент по паролю, который лежит в открытом виде в окружении продуктового хоста, и отдельная учётка там ограничивает ущерб записью. Снят ровно один слой и ровно с витрины. Файл metrics-ui.caddy.snippet и его bind-mount оставлены на месте: диффу так меньше, вернуть слой можно одной строкой. Гард импортов (#3104) проверяет обратное направление - что каждый import покрыт маунтом, - поэтому лишний маунт его не трогает. Проверено: scripts/check-caddy-snippet-mounts.py зелёный (6 конфигов, 7 маунтов); конфиг с новой версией infra.caddy проходит caddy validate в одноразовом контейнере на Beget - Valid configuration.	2026-08-26 15:21:04 +03:00
bot-backend	124cfb3d5d	feat(observability): /metrics в обоих бэкендах — счётчики, задержка, дашборд ... Третья часть #3078 и единственная, трогающая прод-код. До неё числовых рядов у приложений не было вовсе: только логи и исключения в GlitchTip. Класс отказов «отвечает, но медленно» и «отдаёт 401 потоком» в такой картине невидим — исключения нет, строка в логе выглядит обычной, а продукт при этом не работает. Метка route — ШАБЛОН маршрута, а не путь запроса. Это несущее решение, а не деталь: кадастровый номер или идентификатор заявки в метке даёт новый временной ряд на каждую сущность, а ряд у Prometheus стоит памяти постоянно, а не в момент запроса. Самый известный способ уронить мониторинг тем самым мониторингом. Незаматченные пути (404, сканеры) сведены в одну метку, иначе тот же взрыв устроит любой бот, перебирающий адреса. Оба свойства сторожатся тестами, а не комментарием: тест бьёт тремя разными идентификаторами и требует ОДИН ряд. Слой регистрируется последним и потому оказывается самым внешним. Изнутри RBAC-гварда не видно ни отказов авторизации, ни времени, которое он тратит на резолв сессии в БД auth, — а именно этот путь уже давал инцидент с блокирующим I/O в middleware (#1202). Упавший исключением запрос считается как 500 в finally: без этого он просто отсутствовал бы в счётчике, то есть ровно тогда, когда метрики нужнее всего. Путь публичен ВНУТРИ и закрыт СНАРУЖИ — это два разных периметра. Скрейп идёт из docker-сети, где заголовка X-Authenticated-User нет ни у кого, поэтому /metrics внесён в _PUBLIC_PATHS обоих бэкендов; иначе агент получал бы 401 и метрик не было бы вовсе. Наружу путь не открывается ни через gendsgn.ru, ни через meraocenka.ru, и вдобавок закрыт явным respond 404 в обоих site-блоках — чтобы закрытость осталась решением, а не следствием текущего порядка директив. Ограничитель частоты и аудит «Меры» не трогались: оба смотрят только на пути под /api/, скрейп под них не попадает. Проверено тестом, а не чтением. Прод-поведение не меняется ничем, кроме нового публичного пути: ни один существующий обработчик, гвард или маршрут не тронут. Refs #3078	2026-08-26 11:30:18 +03:00
bot-backend	309d273f3f	feat(observability): стек метрик и логов — Prometheus, Loki, Grafana, агенты на обоих хостах ... Метрик в проекте не было ни одной: ни экспортеров, ни /metrics в бэкендах, единственный канал наблюдения — journald, единственный сигнал об аварии — исключение в GlitchTip. Из-за этого целый класс отказов невидим в принципе: задача рапортует done, строк ноль, исключения нет. Так протухли данные на семь месяцев (#2998), 34 дня был мёртв house_imv_backfill (#2698), 8 суток писал ноль newbuilding_enrich (#2767), 91 день копилось раздутие listings (#2992). Grafana не заменяет GlitchTip: ошибки остаются там. Grafana OSS не принимает Sentry DSN ни одним компонентом, а скрубберы в before_send — требование 152-ФЗ. Здесь появляется другой класс данных: ряды и алерты по трендам. Наблюдатель поставлен у ДРУГОГО провайдера, чем наблюдаемое: серверная сторона на Beget, рядом с GlitchTip. Если ляжет Poincare, мониторинг должен об этом сказать, а не лечь вместе с ним. Транспорт push, а не pull: агент на Poincare шлёт remote_write и логи исходящим HTTPS, поэтому там не открывается ни одного входящего порта сверх 22/80/443. При обрыве канала Alloy копит в WAL и досылает — pull-скрейп в той же ситуации терял бы точки именно в аварии, ради которой мониторинг и нужен. Два контура доступа с разными учётками. Пароль приёмника по построению лежит открытым на продуктовом хосте, значит его компрометация неизбежна вместе с хостом; будь это учётка витрины, утёк бы и доступ к дашбордам. GlitchTip читается прямым SQL, а не Sentry-плагином: у плагина на 6.1.6 stats_v2 отдаёт 500 (баг GlitchTip #381), Events/Discover — 404 (#416), а в grafana/sentry-datasource слово glitchtip не встречается ни разу. Схема сверена на живой базе: колонка времени называется timestamp, а не received, и отдельной таблицы IssueIndex не существует — агрегаты лежат на самой issue_events_issue. Алерты за профилем alerts: канал доставки — открытый вопрос #3078, и стек не должен на нём стоять. Деплой предупреждает, что уведомлять пока некому. Каждая настройка, способная отказать молча, закрыта явно: ретенция Prometheus задана и по времени и по размеру, retention_enabled у компактора Loki (без него retention_period не работает вовсе), путь к журналу и запуск Alloy от root (иначе агент читает ноль записей без ошибки), проверка Caddy до перезагрузки (на этом хосте тот же Caddy держит git, errors и obsidian). Refs #3078	2026-08-26 10:45:54 +03:00
lekss361	60cb510ef2	refactor(caddy): разделить site-блоки по хостам под переезд (#3062)	2026-08-23 21:52:48 +00:00