63 commits

Author	SHA1	Message	Date
bot-backend	204e2e09de	Merge pull request 'fix(deploy): подменять фронт МЕРЫ отдельной командой — окно простоя 30–90 с уходит (#3274, часть 1/2)' (#3442) from fix/3274-part1-deploy-swap into main	2026-09-11 20:21:52 +00:00
bot-backend	134985a624	fix(smoke): отказ TLS-сертификата — это FAIL, а не «ответа нет» ... Повтор запроса включался на ЛЮБОМ ненулевом rc curl, хотя собственный комментарий рядом называл сетевой класс (6/28/35/52/56). Протухший, чужой или самоподписанный сертификат даёт rc=60 (замер: expired.badssl.com, self-signed.badssl.com, wrong.host.badssl.com) — и измеренный регресс периметра уезжал в колонку «периметр этой проверкой НЕ проверен», потратив на детерминированный отказ три попытки и 6 c пауз. Ровно этот отказ и есть предмет проверки 5b: без site-блока Caddy не выпускает сертификат. Коды сетевого класса вынесены в NETWORK_RC рядом с комментарием, чтобы описание и поведение не разъезжались; повтор делается только по ним. rc=7 (соединение отвергнуто) добавлен туда же — ответа при нём тоже нет. curl_failed печатает rc в обеих ветках: строки RETRY при SMOKE_ATTEMPTS=1 нет вовсе, и «домена нет» (6) было не отличить от «сертификат протух» (60). timeout-minutes 10 → 40: худший случай (прод не отвечает — мертвы все 43 проверки) = 43 × 53 c ≈ 38 мин, в 10 минут помещалось ~8 мёртвых проверок, и job убивали ДО печати FAIL-строк и итога — в том самом сценарии, ради которого правка и делалась.	2026-09-12 01:07:11 +05:00
bot-backend	dacd298b21	fix(deploy): подменять фронт МЕРЫ отдельной командой — окно 30–90 с уходит ... Публичный лендинг meraocenka.ru лежал 30–90 с на КАЖДОМ деплое (#3274). Причина не в скорости подмены контейнера: она стоит полсекунды. `docker compose up -d` со СПИСКОМ сервисов работает в две фазы — сначала create (старый контейнер каждого сервиса останавливается и УДАЛЯЕТСЯ, иначе занято container_name), потом start, в порядке зависимостей и с ожиданием их условий. Между фазами старого фронта уже нет, а новый ещё не запущен. Прод, 10.09, два деплоя подряд (docker inspect .Created/.StartedAt): пачка сервисов: tradein-backend создан 15:01:40 → запущен 15:02:10 (30 с), в логе Caddy три 503 на лендинге: 15:01:46/:52 и 15:02:06; ОДИН сервис: tradein-frontend создан 16:42:17.5 → запущен 16:42:18.0 (0,5 с), 503 в логе нет ни одного. Тот же двухфазный порядок воспроизведён на стенде (реальный образ фронта + Caddy 2): соседи создаются сразу, стартуют через 41 с. Поэтому frontend убран из общего `up -d $SERVICES` и пересоздаётся своей командой после пачки: в его графе один сервис, create и start идут подряд. Остаток ~0,5 с добирает ретрай подключения в Caddy — отдельным коммитом, он мержится своим путём (caddy_only → graceful reload, без пересборки). Проба для замера на живом деплое — scripts/probe-deploy-window.sh: считает коды и САМУЮ ДЛИННУЮ серию не-200 в секундах, 000 отдельной строкой (его даёт и отбой периметра, не только простой). Запускать НА хосте прода: с внешнего адреса частая серия сама ловит 30–50 % 000. Refs #3274	2026-09-12 00:44:46 +05:00
bot-backend	c0e45b48d3	fix(smoke): отличать «ответа не было» от «код не тот» в смоуке периметра ... Прогон perimeter-smoke-mera на голове main (a659b187) покраснел на двух последних проверках с кодом `000`. `000` у curl — это не «пришёл неверный код», а «ответа не было вовсе»: периметр был цел, те же пути вручную отдавали 503 и 405 от приложения (server: uvicorn, не заглушка Caddy). Замер причины (внешний IP, /trade-in/api/v1/me): серия без пауз — 5 обрывов из 12, с паузой 0.5 c — 6 из 12, с паузой 2 c — 0 из 8; с самого хоста прода — 0 из 10. Приложение отвечает, частую серию запросов с одного адреса отбивает вход. Смоук шлёт 44 запроса подряд и попадает под тот же эффект, поэтому падают последние проверки списка. Что сделано (ожидания и список путей НЕ тронуты): - один общий curl_try, через который идут все запросы смоука. Повтор только при «ответа не было» — признак берётся у самого curl (ненулевой код возврата), ответ с «не тем» кодом для curl успешен и не повторяется никогда, иначе ретрай маскировал бы настоящий регресс; - отдельная формулировка FAIL (ответа нет) + итоговая строка «БЕЗ ОТВЕТА: N проверок» — чтобы читатель красного лога не искал регресс периметра там, где измерения не было; - пауза 2 c между проверками. Наименьшая величина, у которой есть замер: 0.5 c измеренно не помогает, промежуточные значения не мерил никто; - timeout-minutes воркфлоу 5 → 10: обычный прогон 89 c → 160 c (замер), а неотвечающая проверка стоит до 3×15 c таймаута плюс паузы, и job убивали бы до печати FAIL-строк. Побочно тем же сторожем закрыты места, где обрыв врал диагнозом: в check_redirect_location он читался как «Location не тот», а обрыв на загрузке лэндинга — как «сам лэндинг сломан». Проверка правки: прогон до (89 c, 43/43 PASS) и после (160 c, 43/43 PASS); подставной curl, роняющий каждый нечётный запрос, — 44 повтора, итог зелёный; фальсификация с подменённым ожиданием (/me → 200) и неверным URL (/oferta-net-takogo) — обе строки красные, повторов ноль, выход 1.	2026-09-12 00:28:55 +05:00
bot-backend	a82382f47a	feat(mera-b2c): микроразметка schema.org и картинки превью для публичного сайта ... Сайт открыт для индексации 10.09.2026, но поисковику он до сих пор представлялся девятью страницами без единого структурированного факта о том, кто их публикует и что продаёт, а ссылка на него в мессенджере разворачивалась голым текстом без картинки. МИКРОРАЗМЕТКА. Конструкторы узлов вынесены в `_lib/schema.ts` — чистый модуль без React, по образцу соседнего `_lib/analytics.ts`. Все значения берутся из `content.ts`, ни одной строки не продублировано: - `Organization` + `WebSite` одним `@graph` в layout поддерева, то есть на всех девяти страницах сразу. Остальные узлы ссылаются на организацию через `@id`, а не повторяют реквизиты у себя. - `Service` с `Offer` на лэндинге. - `FAQPage` в блоке возражений. - `BreadcrumbList` на статьях, статье, документах и странице для бизнеса — ровно по тем крошкам, что видны на экране. - Существующий `Article` переведён на ссылку `publisher: { "@id": ... }`. РАЗМЕТКА НЕ ОБЕЩАЕТ ТОГО, ЧЕГО НЕТ. Два места, где это стоило внимания: - `Offer.availability` вычисляется из `PUBLIC_ESTIMATE_ENABLED`. Флаг сейчас `false` (платёжного контура в коде нет), поэтому в разметку уходит `PreOrder`, а не `InStock`: цена опубликована, купить нельзя, и врать об этом поисковику нечего. Включится приём оплаты — значение сменится само. - `FAQPage` строится из того же массива `ITEMS`, который рисует `<details>`, а не из `FAQ` напрямую: в `ITEMS` часть вопросов заменена макетными формулировками, и разметка от сырого `FAQ` разошлась бы с видимым текстом молча. Выдуманных дат, рейтингов и отзывов не добавлено нигде. КАРТИНКИ. Две штуки, и это не дубль: `og-mera.png` 1200×630 — превью ссылки, `logo-mera.png` 512×512 — логотип организации в разметке, который поисковик обрезает близко к квадрату и где баннер превратился бы в обрезок надписи. Исходники обеих лежат рядом в `scripts/og/*.html` вместе с командой перерисовки: картинка должна оставаться правимой, а не только переоткрываемой в графическом редакторе. Готовые PNG, а не `opengraph-image.tsx`: satori внутри `ImageResponse` рисует только переданными ему байтами шрифта и кириллицу по умолчанию не покрывает, плюс не видит ни CSS Modules, ни наших `--b2c-*`. Разбор — в шапке `scripts/og/og-mera.html`. `images` продублирован в `twitter`: Next не переносит их из `openGraph`, когда метаданные заданы объектом, и карточка обещала бы крупное превью без картинки. ПЕРИМЕТР. Обе картинки лежат в `public/` и раздаются Next'ом по basePath-корню, куда rewrite `@meraPages` не достаёт, — отсюда два отдельных `handle` по образцу robots.txt. Оба названы в `ROOT_HANDLES_ALLOWED`, иначе двусторонний гейт периметра покраснел бы, и это правильно: корневой `handle` — вторая дверь в тот же периметр. Смоук проверяет не только 200, но и Content-Type: перепутанный rewrite отдаёт 200 с HTML, обходчик мессенджера молча его отбрасывает, и по логам приложения этого не видно — запрос туда не доходит. Проверено: tsc, eslint, 215 тестов mera-public, изоляция B2C-дерева, caddy validate, bash -n смоука, прод-сборка с basePath и разбор отрендеренного HTML — JSON-LD парсится, og:image и twitter:image на месте. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CiUFZ3rmTNpp3DRajUo8KQ	2026-09-10 19:06:35 +03:00
bot-backend	2220df8741	fix(mera): версия согласия ПДн отстала от новой редакции политики + смоук ждал не тот код ... ДВА ПОСЛЕДСТВИЯ #3436, обнаруженные на прогоне против прода. 1. ДЕПЛОЙ МЕРЫ БЫЛ ЗАБЛОКИРОВАН. В #3436 политика конфиденциальности получила раздел про cookie, то есть новую редакцию, и `PRIVACY_APPROVAL` во фронте стал «№ 2 от 10 сентября 2026 г.». Бэкендовая `_CONSENT_POLICY_VERSION` осталась на «2026-08-13», а между ними стоит гейт `test_consent_text_frontend_sync.py` — он и упал. Job `test` в deploy-tradein.yml падает → `deploy` пропускается по своему `needs.test.result != 'failure'` → прод остался на старом образе фронта, при том что Caddy обновился отдельным пайплайном. Внешне это выглядело как «задеплоилось наполовину»: UTM на редиректе со слэшем починился, а noindex и robots.txt — нет. Гейт сработал ровно как задуман: версия согласия обязана указывать на ту редакцию документа, которую человек реально видел, иначе снимок согласия в trade_in_leads.consent_policy_version подписан не тем документом. Правим версию, а не тест. Согласия, собранные до 10.09, остаются с "2026-08-13" — в этом и смысл хранить версию per-row. 2. СМОУК ЖДАЛ 404 ТАМ, ГДЕ ПРОД ОТВЕЧАЕТ 401. Проверка «карта сайта МЕРЫ не просачивается через B2B-домен» ожидала 404 от allowlist'а site-блока, но корень gendsgn.ru закрыт пилотным basic_auth, и гейт отвечает 401 РАНЬШЕ, чем запрос доходит до allowlist'а. Проверка была написана без прогона против прода — это честно отмечено в её же комментарии — и упала на первом же запуске. Заведён `check_any`: PASS на любом из перечисленных кодов. Здесь допустимы 401 и 404 — оба означают проверяемое («наружу этого адреса нет»), а какой рубеж ответил первым, к предмету проверки отношения не имеет. Жёсткое ожидание к тому же сломалось бы при снятии пилотного гейта. Красная строка осталась там, где ей место: 200 означал бы реальную течь. Проверено: `pytest tests/test_consent_text_frontend_sync.py` — 6 passed; полный сьют бэкенда МЕРЫ локально 5737 passed; `bash -n` на смоуке чист; `check_any` прогнан против живого gendsgn.ru — PASS на фактическом 401. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CiUFZ3rmTNpp3DRajUo8KQ	2026-09-10 17:43:03 +03:00
bot-backend	671fef758e	feat(mera): Метрика и GA4 на публичном контуре + открытие сайта для индексации ... ЗАЧЕМ. Статьи МЕРЫ публикуются с UTM-метками, но посмотреть, приходил ли по ним кто-нибудь, было физически нечем: веб-аналитики на публичном контуре не было вовсе. Заодно вскрылось, что «толкнуть в выдаче» тоже нельзя — всё дерево mera-public отдавало `robots: noindex, nofollow`. СЧЁТЧИКИ. Яндекс.Метрика и GA4 подключаются ТОЛЬКО в `mera-public/layout.tsx` и никогда в корневом `app/layout.tsx` — иначе счётчик уехал бы в закрытый контур (/v2, /admin, /scrapers, /history), где анонимных посетителей нет, а приватные маршруты сотрудников есть. Идентификаторы приходят build-time (`NEXT_PUBLIC_YM_ID` / `NEXT_PUBLIC_GA_ID`) — канон Dockerfile'а этого проекта: Next инлайнит NEXT_PUBLIC_* на сборке, runtime env их не подхватит. Пустое значение = тег не рендерится вовсе, никаких `ym(undefined)`. Оба build-arg'а прописаны в ОБОИХ блоках CI, включая retry-сборку без кеша. Вебвизор выключен намеренно. Он пишет ввод в поля, а на `/estimate` человек вводит адрес своей квартиры; раздел 9 политики этого не раскрывает. Включать следует одним заходом с правкой политики и маскировкой полей — в коде рядом записано, что именно понадобится. ЦЕЛИ ВОРОНКИ. Десять целей: клик по CTA, начало ввода адреса, адрес выбран, результат с разбивкой по вердикту (ok/thin/none), ошибка расчёта, ошибка валидации, отказ подсказок, показ платного тизера. Кнопок «Проверить квартиру» восемь штук в разных компонентах, все — обычные `<a>` через PublicLink, поэтому вместо восьми копий onClick один делегированный слушатель на document: девятая кнопка подключится сама. Цель «оплата успешна» НЕ заведена — вызова checkout во фронте нет вовсе, PAYMENTS_ENABLED выключен, страницы возврата не существует; вешать её пока не на что. ИНДЕКСАЦИЯ. Снят noindex со всех публичных страниц, добавлены `app/robots.ts` и `app/mera-public/sitemap.ts`, metadataBase, canonical на КОРОТКИЕ адреса, openGraph и JSON-LD Article на главной статье. robots.txt и sitemap.xml разведены по двум разным handle в Caddy не от хорошей жизни: у Next robots.txt — конвенция корня app/, а sitemap живёт в сегменте маршрута, и формы путей не совпадают. 152-ФЗ. Раздел 9 «Файлы cookie и веб-аналитика» в политике (обработчики названы поимённо — этого требует ч. 3 ст. 6) + уведомляющий, не блокирующий баннер. Гейт «названий площадок в публичной копии быть не должно» получил узкое исключение ровно на аналитические словосочетания в политике; голое «Яндекс» как площадка остаётся запрещённым и там. ПОПУТНЫЙ БАГ (замер на живом проде 10.09.2026). `meraocenka.ru/articles/` с UTM-метками отдавал 301 на адрес БЕЗ query — матчер @meraShortSlash собирал цель из regex-захвата пути и терял параметры. Код ответа при этом оставался 301, поэтому смоук проблему не видел. Мессенджеры и автолинкификаторы дописывают слэш сами, то есть атрибуция терялась именно на трафике по опубликованной ссылке. Починено тем же приёмом, что у соседних матчеров; в смоук добавлена проверка буквального Location. ГЕЙТЫ. `isPublicPath` и периметр-тест узнали про новые машинные адреса; noindex-гейт развёрнут (падает, если флаг вернулся) и расширен на строковую форму `robots: "noindex"`; заведена проверка, что корневых `handle` в site-блоке не появляется без объявления — раньше эту дверь гейт не видел. Проверено: tsc и eslint чисто, `npm run build` проходит, robots.txt и sitemap.xml отдаются по нужным адресам, при пустых ID в HTML нет ни одного обращения к mc.yandex.ru и googletagmanager, `caddy validate` валиден, изоляция mera-public от B2B не нарушена. Два теста LoginPage падают и на нетронутом дереве — не наши. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CiUFZ3rmTNpp3DRajUo8KQ	2026-09-10 16:52:31 +03:00
bot-backend	6e0a34a683	Merge remote-tracking branch 'origin/main' into HEAD ... # Conflicts: # scripts/smoke-mera-perimeter.sh	2026-09-06 01:16:29 +05:00
bot-backend	01367c2a9e	fix(smoke): бить в существующий роут /api/v1/trade-in/history ... Проверка «trade-in /api/v1/history — 401 anonymous» ходила по несуществующему пути: ручка объявлена как @router.get("/history") в app/api/v1/trade_in.py, а роутер подключён с префиксом /api/v1/trade-in, то есть внешний путь — /trade-in/api/v1/trade-in/history. Годы проверка была зелёной случайно: guard отвечал 401 на любой путь. После #3352 несуществующий путь отдаёт 404, и проверка покраснела честно.	2026-09-06 01:04:13 +05:00
bot-backend	990a59e469	fix(rbac): анониму на admin-префиксе отвечать 404, а не 401 ... #3360. Периметр /trade-in/api/v1/admin/* снаружи не срезан (caddy/sites/apps.caddy: блок `handle /trade-in/api/*` стоит выше `import caddy/users.caddy.snippet`), и срезать его нельзя: admin-UI кабинета зовёт эти пути ИЗ БРАУЗЕРА (12 файлов tradein-mvp/frontend/src — scrapers/**, components/scrapers/**, admin-audit-api.ts, GuardedRoute). Значит внешний аноним доходит до rbac_guard, а после #3324 (несуществующий путь → 404 роутера) 401 на существующей ручке стал оракулом: перебором имён восстанавливался список admin-API. Все три ветки «личность не установлена» (нет X-Authenticated-User, auth_mode=db_only, подделанный заголовок без #2213-секрета) на admin-префиксе теперь отдают ровно то же, что роутер даёт на несуществующий путь. Аутентифицированные не тронуты: admin — 200, не-admin — 403 «admin only» (прятать наличие ручки от опознанного человека незачем). Смоук периметра: пара admin-путей — существующий /admin/proxies и несуществующий /admin/users — оба обязаны быть 404 снаружи.	2026-09-06 00:51:09 +05:00
bot-backend	3e481b0276	fix(caddy): смонтировать deploy-window сниппет — иначе Caddy не адаптирует конфиг ... Каталог caddy/ пробрасывается в контейнер ПОФАЙЛОВО (users + metrics-*, плюс каталоги sites/ и local/). apps.caddy импортирует `../deploy-window.caddy.snippet`, которого без этой строки в контейнере нет: Caddy падает на 'File to import not found', уходит в restart-loop и роняет ВСЕ домены хоста — ровно постмортем #3102. Гейт scripts/check-caddy-snippet-mounts.py на ветке был красный (две строки apps.caddy + сам сниппет), после этой строки зелёный. Смоук периметра: 503 на payments/notify перестал что-либо доказывать — тот же код теперь отдаёт заглушка окна деплоя. check_post получил необязательный шаблон-дискриминатор: код совпал, но в ответе `Retry-After: 30` или `service_unavailable` — это Caddy, а не приложение, и это FAIL. Refs #3274	2026-09-05 23:06:54 +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	078f102841	Merge pull request '«Для бизнеса» вела на форму входа — заведена страница /business' (#3294) from feat/mera-business-page into main	2026-08-31 09:14:34 +00: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	f31cb56081	прод: лендинг ходил в чужой бэкенд — имя сервиса двоится между продуктами ... Публичный лендинг отдавался БЕЗ витрины: без ленты сделок, без строк сверки «прогноз против факта», без подписи разброса. Страница про точность — без единого доказательства. Отдавалось 106 КБ вместо 241 КБ. Причина. ПТИЦА и МЕРА — разные compose-проекты, но оба назвали свой сервис backend и оба подключены к общей сети gendesign_shared. Изнутри фронта: backend → 172.18.0.6 (МЕРА) + 172.18.0.9 (ПТИЦА) tradein-backend → 172.18.0.6 BACKEND_URL=http://backend:8000 уводил серверный рендер в бэкенд ПТИЦЫ, тот отвечал 401 no authenticated user, и страница рендерилась пустой. Отказ тихий вдвойне. fetch не бросает — приходит валидный HTTP-ответ, просто чужой. И имя двоится, поэтому часть перегенераций попадала в правильный адрес: утром страница была с данными, к обеду без них, и это выглядело случайной поломкой, а не ошибкой конфигурации. DATABASE_URL болен тем же: @postgres:5432 мог уйти в базу ПТИЦЫ. Там спасало лишь несовпадение кредов — отказ вместо тихого чтения не тех данных. Полагаться на это нельзя: защита держится на том, что у чужой базы нет пользователя с нашим паролем. Переведён на однозначное имя во всех трёх сервисах. Гейт check-compose-ambiguous-hosts.py: пересечение имён сервисов обоих compose и запрет ссылаться на них как на хост. Селфтест по конвенции соседних гейтов — он провалился дважды на моих же фикстурах (в них не было общего имени, то есть ловить было нечего), и это ровно то, ради чего селфтест и нужен. Фальсификация на настоящем файле: возврат backend:8000 даёт точную строку 479, возврат @postgres — все четыре ссылки.	2026-08-30 16:07:41 +05:00
bot-backend	e13374e319	fix(smoke): периметр требовал 401 от вебхука, который PR-D3 открыл намеренно ... Деплой main после #3237 покраснел на perimeter-smoke: FAIL: trade-in payments/notify — 401 anonymous -> got '405', expected 401 Это не регрессия, а сработавшая канарейка. PR-D3 (#3231) внёс notify в `_PUBLIC_PATHS` осознанно: это вебхук банка, он обязан быть достижим без наших заголовков. В теле того PR прямо сказано, что 401 здесь стал бы признаком поломки («вебхук банка получил бы отказ»). Ожидание в смоуке обновить забыли — ровно то, о чём предупреждал комментарий над блоком в PR-D2. Замена не ослабляет проверку, а усиливает: вместо GET→401 теперь POST→503, что утверждает сразу два факта — маршрут существует (404 означал бы старый образ) И приём платежей выключен (`payments_enabled=False`). 200 здесь поймает включение флага, сделанное мимо этого смоука. Плюс GET→405 закрепляет, что путь принимает только POST. Проверено на живом проде: POST notify 503, GET notify 405, checkout 401, meraocenka 404 на обоих путях; payments/payment_notifications/ payment_entitlements пусты. Полный прогон скрипта — ALL CHECKS PASSED. Ожидания под meraocenka.ru не тронуты: PR-D4 не смержен, 404 там остаётся канарейкой.	2026-08-29 18:49:43 +03:00
bot-backend	4b019ebd67	chore(claude): retire autonomous bot-pipeline ... Ролевые окна (claude --strict-mcp-config --mcp-config .claude/mcp/<role>.json) не используются — отказ по стоимости: слишком много токенов на простых задачах. Удалено (25 файлов): - scripts/: start-bot, start-{analyst,backend,frontend,qa,reviewer}, setup-bot-env - .claude/mcp/: 5 per-role MCP-конфигов - .claude/commands/: 6 work-as-* - .claude/agents/: 6 auto-* + _autonomous_pickup Ссылки в выживших файлах поправлены: CLAUDE.md, README.md, git-pr.md, deep-review-phases/phase-5-verdict.md, deep-code-reviewer.md, cleanup-stale-claims.sh. Self-extending guard сохранён — из него убраны только имена удалённых файлов, сам запрет на self-merge правил пайплайна цел. Универсальные воркеры не тронуты: backend-engineer, frontend-engineer, database-expert, devops-engineer, tech-analyst, code-reviewer, qa-tester, deep-code-reviewer.	2026-08-28 22:27:00 +03: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	de56b8ae01	feat(ops): сторож расхождения «прод ↔ main» — молчаливый недоехавший деплой становится видимым (#3029) ... 27.08 прод сутки жил на позавчерашнем коммите, и это нашлось только руками. Замена IP сервера (#3110) осиротила секрет DEPLOY_HOST: deploy.yml падал на `dial tcp ***:***: i/o timeout`, при этом CI оставался зелёным, PR продолжали мержиться, а deploy-infra.yml исправно обновлял Beget и создавал впечатление, что всё в порядке. Проверок, которые спрашивают не «прошёл ли прогон», а «доехал ли код», не было ни одной. Этот сторож — ровно такая: ежечасно читает HEAD с прод-хоста и сверяет с tip main. Три исхода вместо двух. «Хост не ответил» (2) отделён от «на хосте не тот код» (1) — это разные аварии с разной первой командой в разборе, и сегодня погорели именно на их смешении: недоступность выглядела как обычный красный прогон. Льготный период 30 минут гасит ложную тревогу на деплое, который ещё в полёте: ежечасный сторож неизбежно попадёт в окно между мержем и концом выката, а сторож, которого научились игнорировать, хуже отсутствующего. Логика вынесена в scripts/check-deploy-drift.sh и не ходит по сети — SSH живёт в workflow, где секреты. Благодаря этому тест ИСПОЛНЯЕТ настоящий скрипт, а не пересказывает его: ошибка в самом bash видна только при запуске. Read-only: один ssh и git rev-parse, ничего не деплоит.	2026-08-27 12:35:43 +03:00
bot-backend	0e4beb8457	chore(hooks): точечный allowlist на три ключа метрик вместо снятия гарда ... Владельцу понадобились креды Grafana (basic_auth Caddy + внутренний вход), а они лежат в backend/.env.runtime, который check-secret-read.py закрывает целиком. Снимать гард нельзя: в том же файле prod DB-пароли и токены Forgejo/GlitchTip. Вместо этого — ALLOWED_KEYS из трёх ключей (METRICS_UI_PASSWORD, GRAFANA_ADMIN_USER, GRAFANA_ADMIN_PASSWORD) и разрешение ровно на anchored-греп по ним. Условия намеренно жёсткие, чтобы «прочитать один ключ» нельзя было развернуть в «выгрузить файл»: блокируются инверсия (-v / --invert-match), пайпы, цепочки ; && ||, подстановки $(...) и обратные кавычки, редиректы. Тест на 10 кейсов: разрешён только anchored-греп по ключу из списка; отбиты инверсия, пайп, цепочка, редирект, подстановка, чужой ключ, греп без якоря ^ и обычный cat. Проверяется и функция, и хук end-to-end через настоящий stdin-payload. Гард в деле: он же отбил эту самую команду коммита, когда текст сообщения содержал имя закрытого файла рядом с read-verb.	2026-08-26 13:09:37 +03:00
bot-backend	beafe6925b	fix(observability): агент не падает из-за переменной чужой роли (#3078) ... Джоба agent-apps упала целиком: error while interpolating services.postgres-exporter-infra.environment. DATA_SOURCE_NAME: required variable INFRA_EXPORTER_DSN is missing a value INFRA_EXPORTER_DSN нужен экспортеру с profiles: ["infra"], который на продуктовом хосте не поднимается вовсе. Но compose интерполирует ВЕСЬ файл до фильтрации по профилям, поэтому `${VAR:?}` роняет команду из-за чужой переменной. Вместе с агентом не поднялись alloy, node-exporter и cadvisor, которым никакой DSN не нужен. Симметрично упал бы и инфраструктурный агент - на двух продуктовых переменных. Второй дефект в той же цепочке: GENDESIGN_EXPORTER_DSN тоже отсутствовал. setup-metrics-exporter-dsn.sh читает только runtime-файл окружения бэкенда, а DATABASE_URL и TRADEIN_DATABASE_URL живут в основном. Значит подстановка всегда была пустой, add_key печатал "нечем заполнить" и выходил с кодом 0 - мягкий пропуск встречался с жёстким требованием compose. Стало: - compose: `:-` вместо `:?` у трёх DSN. Интерполяция больше не может упасть. - deploy-metrics.yml: профиль экспортеров включается, только если нужные ЭТОЙ роли DSN заполнены; иначе ::warning и агент поднимается без экспортера. Громкость не убрана, а перенесена туда, где роль известна. Тот же приём, что уже применён к Alertmanager в джобе server. - setup-metrics-exporter-dsn.sh: читает оба файла окружения (базовый, затем runtime - он перекрывает). Пишет по-прежнему только в runtime, лишних копий пароля не заводит. Почему `:-` не ослабление: пустой DATA_SOURCE_NAME поднял бы экспортер, который молча не отдаёт метрик, - ровно тот тихий отказ, ради которого весь стек и заводится. Поэтому пустой DSN теперь означает "профиль не включаем", а не "поднимаем пустым". Известное следствие, отмеченное в коде: INFRA_EXPORTER_DSN не собирает никто - скрипт знает только про GENDESIGN_/TRADEIN_ и работает на продуктовом хосте. Пока это так, инфраструктурный агент будет честно предупреждать, что метрик Postgres инфры нет, вместо того чтобы падать целиком. Тесты (3) структурные, проверяют оба конца инварианта: обязательности не вернулись в compose; каждая DSN-переменная проверяется в деплое; профили не захардкожены. Фальсификация: на исходных файлах краснеют все три.	2026-08-26 12:45:31 +03:00
lekss361	1da2eee142	Merge pull request 'fix(observability): стек не поднимался — привилегированную роль спрашиваем у контейнера, а не угадываем (#3078)' (#3105) from fix/3078-metrics-role-discovery into main ... Reviewed-on: #3105	2026-08-26 09:27:29 +00:00
bot-backend	33bc7e4acf	fix(observability): привилегированную роль спрашиваем у контейнера, а не угадываем (#3078) ... Стек наблюдаемости не поднялся ни на одном хосте после мержа #3099: джоба server упала, agent-apps и agent-infra пропустились как зависимые. Причина (задача 23657, 26.08 08:55): err: ОШИБКА: не нашёл роль с правом CREATE ROLE в gendesign-infra-postgres setup-metrics-grafana-role.sh искал привилегированную роль перебором трёх имён - glitchtip, forgejo, postgres. Ни одно не совпадает ни с одним реальным кластером проекта: infra-postgres -> infra, gendesign-postgres-1 -> gendesign, tradein-postgres -> tradein. Комментарий над перебором сам предупреждал, что "угадывать postgres неверно", и дальше шло угадывание. Замер на живом контейнере 26.08 (read-only, ничего не создавалось): POSTGRES_USER изнутри контейнера: infra glitchtip - отказ, forgejo - отказ, postgres - отказ, infra - 1 Стало: имя берём из POSTGRES_USER самого контейнера - это та переменная, которой роль и создана при initdb, то есть источник истины. Прежний список оставлен ПОСЛЕ него запасным путём для кластера не из образа postgres. Попутно - глоб в paths деплоя. Воркфлоу запускает ТРИ setup-скрипта, а в триггере стоял только setup-metrics-secrets.sh: правка двух остальных не заводила выкат, и на хосте молча оставалась старая версия. Тот же класс, что #2203 закрыл глобом ops/*.sh. Добавлен тест, который сверяет запускаемые скрипты с шаблонами paths - на исходном воркфлоу он краснеет, указывая на setup-metrics-exporter-dsn.sh. Тесты (6) исполняют РЕАЛЬНЫЙ скрипт с подставным docker и проверяют фактический выбор роли, а не наличие правильных слов в комментарии. Фальсификация: на исходном коде краснеют 3 из 5 ролевых тестов; проходят только те два, что фиксируют сохранённое поведение (запасной перебор и громкая ошибка при отсутствии привилегий). tests/ops целиком - 28 passed.	2026-08-26 12:08:37 +03:00
bot-backend	46b42c80db	ci(caddy): гард — import обязан быть покрыт volume-маунтом ... Follow-up к #3103. Прод лёг на ~30 минут потому, что PR завёл `import ../metrics-*.caddy.snippet` в caddy/sites/infra.caddy, но не добавил bind-монты этих файлов в docker-compose.prod.yml. Соседний гард `caddy validate` эту дыру не ловит принципиально: он копирует каталог caddy/ целиком (`docker cp caddy ...`), а на проде смонтированы только отдельные файлы плюс два каталога. Расхождение между «что лежит в репозитории» и «что реально видит контейнер» видно только если сверять с маунтами. check-caddy-snippet-mounts.py разбирает bind-монты сервиса caddy:, резолвит каждый `import` в Caddyfile / caddy/sites/*.caddy / caddy/*.caddy.snippet относительно КОНТЕЙНЕРНОГО пути импортирующего файла и падает, если цель не покрыта ни одним маунтом. Именованные сниппеты `(name) { }` пропускаются, для glob/placeholder-импортов (`caddy/sites/{$CADDY_SITES:*}.caddy`) проверяется каталог. --selftest воспроизводит ровно баг #3102.	2026-08-26 12:07:29 +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
bot-backend	f2945b7157	fix(ci): деплой падает громко, если :latest отстаёт от головы по компоненту (#2950) (#3023)	2026-08-21 12:19:07 +00:00
bot-backend	e86f0782da	ci: смоук периметра МЕРЫ запускается сразу после деплоя (#2917) (#2922)	2026-08-19 08:13:49 +00:00
bot-backend	b1fb7bb055	Merge remote-tracking branch 'forgejo/main' into feat/mera-public-api ... # Conflicts: # tradein-mvp/backend/app/core/rbac.py	2026-08-16 09:28:41 +03:00
bot-backend	7424c283d5	feat(mera/b2c): отдельный экран оценки на meraocenka.ru и короткие адреса ... ## Экран проверки — /estimate Проверка квартиры вынесена на собственный адрес: там у автокомплита есть место под список подсказок, а у результата — место рядом с полями. Форма в герое лэндинга осталась входной точкой и уводит сюда, донося набранное через sessionStorage (НЕ через query — адрес в URL попал бы в access-лог Caddy рядом с IP посетителя, а мы на той же странице обещаем ничего не хранить). Показывает живую пробу покрытия: сколько похожих квартир продаётся рядом и сколько в среднем висят их объявления. Ни одной рублёвой цифры — цену продаёт платный шаг. Тексты вердикта вынесены чистой функцией (coverage-copy.ts) и покрыты тестами: подпись под возрастом обязана говорить «объявление», а не «продаётся» (выборка цензурирована), при неизвестном возрасте плитки нет вообще, а пустая когорта объясняется как факт о рынке с подсказкой, что поменять, — директива «никогда не блокировать вывод». ## Короткие адреса Человек больше не видит /trade-in/mera-public/... — только /, /estimate, /oferta, /refund, /privacy. Длинные адреса отдают 301 на короткие: у страницы один канонический адрес, старые ссылки живы. Цена решения: ссылки работают только на meraocenka.ru (короткие пути раздаёт этот хост). Открывать лэндинг для проверки нужно там же, а не с gendsgn.ru. Ссылки эмитятся обычным <a> (PublicLink) — next/link подставляет basePath, и href="/estimate" уехал бы на несуществующий /trade-in/estimate. ## Три дефекта, найденных на живом сайте 1. Палитра v3 никуда не доезжала. b2c-tokens.ts не импортировал НИКТО, ни одна --b2c-* переменная не объявлялась, каскад молча пропускал такие декларации — лэндинг отдавал 200 бесцветным. Добавлен мост b2cVars, гейтом стал тест: каждая использованная в CSS переменная обязана быть объявлена. 2. Голый /trade-in/mera-public падал в 404 — матчер был со слэшем и звёздочкой. Ровно туда вела «Главная» в подвале. 3. «Для бизнеса» вела на «/» — то есть на сам лэндинг. Теперь абсолютный адрес B2B-контура. Пункты «Проверьте себя» и «Продажа под ключ» вели на якоря, которых нет нигде: приведены к виду «Статьи» — видны, но не кликабельны. ## Периметр и приватность Подсказки переведены на POST: access-лог публичного домена пишет URI целиком, то есть GET с ?q= сохранял бы адрес квартиры в файл. Тело в лог не попадает. Метод запинен тестом — это часть обещания, а не стиль. П. 5.4 политики ПДн переписан ВМЕСТЕ с кодом: прежний текст утверждал, что адрес не покидает браузер, и это перестало быть правдой. Новый говорит точно — передаётся, используется однократно, в базах не сохраняется. Последнее проверено по коду: suggest() работает без кэша, проба — один SELECT, аудит пишет строку только при наличии username. PUBLIC_ESTIMATE_ENABLED сузился до платного шага (бесплатная проба не хранит ничего, платный расчёт хранит). ## Проверено vitest 47 passed (9 файлов), tsc, next lint, next build, isolation guard 40 файлов, backend 75 passed, caddy validate = Valid configuration. Мутации структурных гейтов: убрать --b2c-accent-text из b2cVars → падает тест палитры убрать /estimate из @meraPages → падает тест маршрутов добавить импорт next/link → падает тест basePath откат → 14 passed Caddyfile добавлен в paths-filter фронтового лэйна: его читает тест маршрутов, и без этой строки правка одного лишь Caddyfile не запускала бы ни один гейт. Refs #2894, #2895	2026-08-16 09:27:04 +03:00
bot-backend	d046eaada2	feat(mera/b2c): публичный API МЕРЫ — /api/public/mera/{suggest,coverage} ... Первый шаг к отдельному B2C-интерфейсу оценки на meraocenka.ru: домен получает собственную поверхность бэкенда вместо того, чтобы тянуть куски закрытого контура. ## Отдельный префикс, а не проброс кусков /api/v1/* На meraocenka.ru действует allowlist-by-default. Открыть там API можно было двумя способами: перечислить нужные v1-пути поимённо — или завести префикс, под которым по определению не лежит ничего закрытого. Выбран второй: при первом одна опечатка в матчере (`/trade-in/api/*` вместо точного пути) открывает наружу весь v1 — ~20 ручек, включая PDF расчётов, фотографии и админку. Цена ошибки, а не удобство. Добавить сюда приватную ручку теперь нужно СПЕЦИАЛЬНО — положив файл в app/api/public/. Случайно нельзя. ## Ноль записей в БД Обе ручки только читают: /coverage — один SELECT, /suggest — прокси автокомплита. Это условие, при котором публичная форма работает ДО контура согласия 152-ФЗ (#2895: сегодня адрес физлица попадает в trade_in_estimates раньше согласия, а пути удаления в бэкенде нет). Платный расчёт, который писать будет, открывается только вместе с ним. ## Делегирование, а не копии Обе ручки вызывают те же функции, что обслуживают закрытый контур (v1.geocode.suggest_addresses, v1.trade_in.coverage_probe). Разбор #2894 показал, чем кончается вторая копия когорты: проба отвечает «данные есть» там, где платный расчёт видит ноль. Публичный ответ переиспользует CoverageProbeResponse — на нём уже стоит гейт «ни одного price-подобного поля». ## Бюджеты Общего 300/60с мало: /suggest через DaData-тир — платный внешний вызов, абуз стоит денег. Свои per-IP окна: 40/мин на подсказки (человек с debounce'ом тратит единицы на адрес), 15/мин на пробу. ## Проверено 11 тестов, из них структурные: набор ручек под /api/public проверяется на РАВЕНСТВО (третья, добавленная без правки теста, роняет сборку) и сверяется с rbac._PUBLIC_PATHS в обе стороны — чтобы не осталось открытого пути-призрака. Рядом висит закрытый маршрут-двойник: без него «аноним получает 200» одинаково зелёный и когда исключение точечное, и когда auth-гейт снят целиком. Мутации: убрать пути из rbac._PUBLIC_PATHS → 7 failed / 4 passed снять бюджет с /coverage → 2 failed / 9 passed откат → 11 passed Плюс 72 passed на связке rbac + coverage + version, `caddy validate` = Valid configuration, ruff чист. Смоук периметра дополнен парой, которую нельзя разделять: публичные ручки отвечают 200 анонимно И /trade-in/api/v1/* на этом домене по-прежнему 404. Зелёная только первая проверка = API открыт целиком, а тест этого не заметил. Refs #2894, #2895	2026-08-15 22:32:53 +03:00
bot-backend	a8fa7364ae	merge(tradein/payments): влить main в feat/tradein-payments-perimeter-hardening ... Слияние main принесло собственные Sentry-скрубберы (redact_telegram_bot_token + stabilize_retry_error_fingerprint) в app/main.py и app/scheduler_main.py — конфликт разрешён композицией, а не выбором стороны: обработчик перед отправкой в GlitchTip теперь прогоняет событие через всю цепочку в указанном порядке: scrub_payment_request_body → scrub_pii_event → redact_telegram_bot_token → stabilize_retry_error_fingerprint (main.py), и без redact_telegram_bot_token в scheduler_main.py (тот процесс не держит TelegramClient) — оба канала, before_send и before_send_transaction, используют один и тот же обработчик. tests/test_sentry_scrub.py: тесты обеих сторон объединены без потерь — PR-D2 платёжный composed-тест (body-wipe + PII-scrub + token-redaction) и весь блок RetryError fingerprint-стабилизации из main сосуществуют в одном файле.	2026-08-15 22:32:28 +03:00
bot-backend	c6243b166f	feat(mera): оферта, политика возврата и утверждённая политика ПДн + реквизиты ... Юридический блокер публичного B2C-запуска (G6 в mera-b2c-paid-flow-decision.md: `LEGAL_ENTITY == null` → нет реквизитов, нет продажи) и входное требование модерации эквайера: оферты не было вообще, а privacy-страница в собственной шапке писала, что она НЕ утверждённая политика по ст. 18.1 152-ФЗ. Что сделано: - content.ts: `LEGAL_ENTITY` заполнен (ООО «ПРОЕКТ ФЛЭТ», ИНН/КПП/ОГРН, адреса, директор, банковские реквизиты), добавлены `SUPPORT_EMAIL`, `SERVICE_PRICE_RUB`, пути и короткие публичные URL документов. Единый источник — подвал, оферта, возврат и ПДн рендерят эти поля, а не повторяют строки. ОГРН сверен с открытыми данными ЕГРЮЛ (в исходном сообщении владельца был с опечаткой …028028, верный …028281). - Новые страницы /mera-public/oferta и /mera-public/refund — редакции владельца от 13.08.2026 дословно, плейсхолдер `[адрес электронной почты]` заменён на support@meraocenka.ru. - privacy/page.tsx переписана на утверждённую редакцию с оператором и реквизитами приказа. Сохранены оба инварианта честности: раздел про страницу ввода адреса условен по `PUBLIC_ESTIMATE_ENABLED` (п. 5.4 — пока публичный расчёт выключен, адрес не покидает браузер), срок хранения оплаченного отчёта рендерится из `PAID_REPORT_RETENTION_MONTHS`, а не числом в тексте (test_paid_retention_text_consistency.py). - Caddyfile: короткие адреса /oferta, /refund, /privacy → rewrite на поддерево лэндинга. Именно они напечатаны внутри документов и уйдут в заявку эквайеру. Пути перечислены поимённо — allowlist-by-default периметра не ослаблен. - smoke-mera-perimeter.sh: три новые проверки на короткие адреса. Публикация оферты НЕ включает приём оплаты: платёжного контура в коде нет, `PUBLIC_ESTIMATE_ENABLED` по-прежнему false. Оферта публикуется раньше кнопки намеренно — без неё эквайер не примет заявку. Проверено локально: tsc, next lint, vitest (29), isolation guard, next build (три страницы пререндерены), pytest test_paid_retention_text_consistency (3), caddy validate + adapt (rewrite на месте), рендер всех трёх страниц через next start — реквизиты, почта и цена на месте.	2026-08-13 20:10:38 +03:00
bot-backend	1f85ef7d4e	fix(tradein/payments): тело нотификации не течёт в мониторинг и аудит, повторы банка не отбиваются лимитом ... PR-D2 платёжного контура МЕРЫ — закрывает утечки до открытия публичных путей (PR-D3/D4), сам ничего не открывает: _PUBLIC_PATHS (rbac.py), Caddyfile, roles.yaml, auth_session.py не тронуты. - sentry_scrub.py: новая scrub_payment_request_body — вырезает event.request.data целиком для /api/v1/trade-in/payments/* (sentry_sdk 2.64 кладёт полное тело запроса в request.data, send_default_pii=False это НЕ гейтит — тот флаг управляет только куками). Плюс расширен _PII_KEYS: customer_email/customer_phone/pan/expdate/cardid/rebillid/token/terminalkey. - main.py, scheduler_main.py, tgbot_main.py (все 3 точки инициализации sentry_sdk.init в проекте) — тот же обработчик проведён в ОБА канала, before_send и before_send_transaction. Мотивирующий инцидент: на соседнем продукте вчера закрыли только error-канал, transaction остался без обработчика вообще. - ratelimit.py: точный путь notify — свой щедрый SlidingWindowLimiter (3000/60с per-IP, идиома support.py) вместо общего лимитера, но НЕ полное отключение — backstop против шторма запросов остаётся, подпись проверяется уже после разбора тела (PR-D3). Только notify, не checkout (тот с сессией). - request_audit.py: notify — в audit skip-набор (defense-in-depth: middleware внешний относительно rbac_guard и читает сырой X-Authenticated-User — спуфнутый заголовок иначе писал бы фальшивые события с атрибуцией admin). - smoke-mera-perimeter.sh: негативные проверки-канарейки — notify/checkout сейчас закрыты 404 (meraocenka.ru, Caddy не проксирует) и 401 (gendsgn.ru, rbac ещё не открыл) с обеих сторон периметра. Тесты: scrub на произвольной глубине + payment-path body-wipe, AST-разбор (не substring — комментарии в этих же файлах сами упоминают before_send_transaction) на проводку обоих каналов во всех точках инициализации, 400 запросов notify без единого 429 + контроль что общий лимитер по-прежнему активен на других путях, notify вне user_events даже со спуфнутым X-Authenticated-User: admin.	2026-08-07 16:17:59 +03:00
bot-backend	482deb4864	fix(migrations): закрепить lock_timeout для блокирующего DDL и ловить невалидные индексы (#2791)	2026-08-07 11:21:28 +00:00
bot-backend	d605f0b938	ci: гейт против публикации занятых на VPS портов в workflow (#2757) (#2759)	2026-08-06 21:40:05 +00:00
lekss361	55254b43e4	feat(mera/b2c): публичный периметр на отдельном домене meraocenka.ru — этап 1 из 8 (#2545) ... Открывает публичный site-блок meraocenka.ru с allowlist-by-default: разрешены только корень лэндинга, его поддерево и _next/static, всё остальное 404. B2B-контур gendsgn.ru не затронут. DNS A-записи для всех трёх доменов на 46.173.16.127 подтверждены до мержа.	2026-08-02 12:51:46 +00:00
bot-backend	0658399f01	fix(devops): cleanup-merged-worktrees.sh — 3 бага, найденные вживую на 69 забытых worktree (#2418)	2026-07-04 13:00:14 +00:00
lekss361	b7d35cfee0	chore(claude): security hardening — dangerous-commands hook, settings в git, restricted DB, throttle (#2150)	2026-07-02 15:23:11 +00:00
lekss361	845f699176	chore(claude-config): secret-read + psycopg2 hooks, tradein.md rule, tradein-mvp globs (#1975)	2026-06-27 10:03:19 +00:00
Light1YT	8a3bae0cda	feat(analyze): per-category OSRM routing (foot vs driving) (#39 A3) ... Walk-relevant POIs (school/shop/park/kindergarten/pharmacy/stops) now route via a FOOT OSRM graph (osrm-walk service), car-relevant POIs (mall/hospital + unknown) keep the DRIVING graph. Validation showed driving overstated pedestrian-proximity distance — median 1.6-2.9x straight-line (#39). - config: osrm_walk_local_url + osrm_walk_categories (frozenset, 9 walk cats) - osrm_client_local: base_url override on get_road_distances_m (default unchanged) - _apply_osrm_road_distances: split POIs by category, per-group OSRM call with independent graceful fallback (one server down -> its group keeps straight-line), in-place write-back by original index; never raises; flag-OFF byte-identical - docker-compose: osrm-walk service (foot graph, internal, mem_limit 1.5g) - build_osrm.sh: CAR=0 gate for foot-only refresh (doesn't touch live car graph) - tests: per-category split, per-group fallback, asymmetric intra-group write-back Still flag-gated (use_osrm_distances OFF) — enabling is a product decision. Refs #39	2026-06-27 04:30:25 +05:00
bot-backend	4fe20a9cbd	feat(devops): self-hosted OSRM routing engine for site-finder (#39) (#1929)	2026-06-26 19:18:21 +00:00
Light1YT	86e9ea2937	fix(week-review): автофиксы код-ревью — 169 issue (label «week ревью 1») ... Многоагентный аудит + имплементация: один воркер на файл, точечные правки. Верификация: py_compile (47/47 .py) + tsc --noEmit (0 ошибок). Unit-тесты не прогонялись (окружение не поднято: rollup native dep / нет pytest-venv). Полностью исправлено (169): #1336, #1337, #1339, #1340, #1341, #1342, #1343, #1345, #1346, #1348, #1349, #1350, #1351, #1354, #1356, #1358, #1359, #1360, #1362, #1364, #1365, #1366, #1367, #1368, #1369, #1370, #1371, #1372, #1373, #1374, #1375, #1376, #1377, #1378, #1379, #1380, #1381, #1382, #1384, #1385, #1386, #1387, #1388, #1389, #1390, #1391, #1392, #1394, #1395, #1396, #1397, #1399, #1400, #1401, #1402, #1403, #1404, #1408, #1409, #1410, #1411, #1412, #1413, #1414, #1415, #1416, #1417, #1418, #1420, #1423, #1425, #1426, #1427, #1428, #1429, #1430, #1431, #1432, #1433, #1434, #1435, #1437, #1438, #1439, #1440, #1441, #1442, #1443, #1444, #1445, #1446, #1447, #1448, #1449, #1450, #1451, #1452, #1453, #1454, #1455, #1456, #1457, #1458, #1459, #1460, #1461, #1462, #1463, #1464, #1465, #1466, #1467, #1468, #1469, #1471, #1472, #1473, #1474, #1476, #1478, #1479, #1481, #1482, #1483, #1484, #1485, #1487, #1488, #1489, #1490, #1491, #1492, #1493, #1494, #1495, #1496, #1497, #1499, #1500, #1501, #1502, #1504, #1505, #1506, #1507, #1510, #1514, #1515, #1516, #1517, #1518, #1519, #1521, #1522, #1523, #1524, #1525, #1526, #1527, #1528, #1529, #1531, #1532, #1533, #1534, #1535, #1536, #1537, #1538 Частично (9, in-file часть, остаток cross-file): #1361, #1419, #1422, #1424, #1470, #1475, #1477, #1480, #1498 Требуют cross-file (3, не тронуты): #1338, #1363, #1421 Пропущено (1): #1539 Не входило в партию: 22 needs-Leha issue (нужны решения владельца). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-15 20:21:11 +05:00
Light1YT	6883d14177	fix(ops): repair broken main-DB backup + harden auth scripts/docs (#71 #427 #429 #428) ... #71 (CRITICAL): backup.sh committed 100644 → git reset --hard on deploy re-asserts non-exec mode → raw-path cron fails Permission denied (last good dump 2026-05-27, no S3). Commit 100755 + chmod ops/*.sh in deploy.yml + size sanity-check (never prune good dumps for a truncated one) + keep-N retention + optional S3 (redacted /etc/default template). Modeled on the working backup-tradein-db.sh. #427: widen basic_auth username regex ^[a-z][a-z0-9_.-]{1,62}$ + literal-escape dotted names in grep probes. #429: replace list_users.sh false-positive grep with anchored awk over basic_auth block. #428: PILOT_ACCESS.md support email → pilot@gendsgn.ru. Closes #71 Closes #427 Closes #429 Closes #428	2026-06-13 20:13:04 +05:00
bot-backend	6e0039dd47	chore(agents): reviewer back to Opus (revert model-part of aa3d012) ... Per user decision: reviewer = Opus (merge-authority needs strong reasoning on verdict); остальные loop-роли остаются Sonnet. Реверсит только model-часть aa3d012 (reviewer→sonnet). - start-bot.ps1: $model = reviewer? opus : sonnet + --model $model - auto-code-reviewer.md: frontmatter model: opus + doc reviewer на Opus	2026-05-31 17:16:57 +03:00
bot-backend	5fa9588935	chore(agents): bot harness tuning — per-role model, forgejo MCP deferral, vault capture, #893 curl hardening ... - start-bot.ps1: --model per-role (sonnet; opus только reviewer); CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=60 - .claude/mcp/*.json: forgejo (~90 tools) deferred во всех ролях; postgres-gendesign deferred в backend/reviewer - auto-analyst.md: knowledge-capture step (status/done → inbox draft → vault-overlord) — закрывает 'волт не обновляется' - forgejo ops через mcp__forgejo__* вместо сырого curl: auto-code-reviewer/backend/qa workflow + _autonomous_pickup contract - #893 guard: бан curl→/tmp→python3 (Windows 404+FileNotFoundError); deferred→ToolSearch; stale tool-name cleanup (deep-reviewer phases)	2026-05-31 16:26:17 +03:00
bot-backend	aa3d012fdf	chore(agents): bot-окна на Sonnet (start-bot --model) + context-hygiene + reviewer/resolver→sonnet (weekly Opus-пул)	2026-05-31 15:39:42 +03:00
lekss361	5cfab0b23e	fix(bots): подключить postgres-tradein MCP в analyst/backend bot-окна (#857)	2026-05-31 06:44:46 +00:00
lekss361	2df8f78747	chore(bots): per-window MCP isolation via --strict-mcp-config ... Каждое bot-окно грузит ТОЛЬКО нужные роли серверы (не все 7+ в каждом окне). Выигрыш: не спавнить heavy-серверы зря (docker postgres в frontend/qa), right-size eager-набор, чистый tool-surface на роль. (Контекст tool-search и так бережёт — deferred ≈ бесплатно; это про процессы + eager + ясность.) - .claude/mcp/{analyst,backend,frontend,reviewer,qa}.json — self-contained per-role конфиги. Секреты НЕ инлайнятся: ${OBSIDIAN_API_KEY}/${GENDESIGN_DB_URI}/ ${GLITCHTIP_TOKEN} через env-подстановку (.mcp.json env expansion, подтв. в доках). Матрица: forgejo+obsidian+context7 eager везде; pg-gendesign eager у backend/reviewer, deferred у analyst; UI (playwright/a11y/lighthouse/shadcn) только frontend/qa; fetch+ glitchtip у backend; glitchtip у qa. - start-bot.ps1: извлекает MCP-секреты из ~/.claude.json (единый источник) → export → запускает `claude --strict-mcp-config --mcp-config .claude/mcp/<role>.json`. Main/интерактивное окно (без start-bot.ps1) по-прежнему видит полный .mcp.json+user.	2026-05-30 11:05:24 +03:00
lekss361	edc5823622	chore(bots): per-role launcher scripts + move bot pipeline to forgejo MCP ... (a) Launcher scripts — больше не экспортировать токен руками: - scripts/start-bot.ps1 <role> — выставляет per-bot identity + токены (FORGEJO_ACCESS_TOKEN для forgejo MCP + FORGEJO_TOKEN для curl-fallback), git-identity, forgejo-bot remote, verify, затем запускает claude. - scripts/start-{analyst,backend,frontend,reviewer,qa}.ps1 — тонкие врапперы. (b) Bots on forgejo MCP (goern) вместо curl: - _autonomous_pickup.md: новая секция «Forgejo операции — mcp__forgejo__* (PRIMARY)» с полным curl→MCP mapping (list_repo_issues / create_pull_request / merge_pull_request / get_pull_request_diff / create_pull_review / add+remove_issue_labels / update_issue / issue_state_change / create_issue_comment). curl_forgejo помечен FALLBACK. - 5 auto-*.md + 5 work-as-*.md: директива «Forgejo API → mcp__forgejo__* tools (mapping в _autonomous_pickup); curl только fallback» + указатель на start-bot.ps1. Gotcha задокументирован: include_org_labels:false на user-репо (lekss361 не org). Требует: рестарт Claude Code (forgejo MCP eager из .mcp.json) + FORGEJO_ACCESS_TOKEN per-window (делает start-bot.ps1).	2026-05-30 10:38:10 +03:00
lekss361	5673dd6298	chore(claude): extend self-extending tripwire + pause-bots guard for stale-claims ... Two safety follow-ups к autonomous-pipeline (flagged в multiagent-аудите): - Self-extending guard расширен: reviewer-bot NEVER merge'ит PR, меняющий _autonomous_pickup.md (claim/kill-switch/merge-FSM contract) или любой work-as-*.md (persona activation) — раньше защищались только git-pr.md Auto-merge policy + CLAUDE.md + auto-code-reviewer.md. Закрывает дыру, где bot мог изменить claim/kill-switch logic без human. Правки в git-pr.md, auto-code-reviewer.md, work-as-reviewer.md. - cleanup-stale-claims.sh: pause-bots early-exit. Без него cron освобождал wip-claim worker'а, приостановленного mid-work (он держит claim до un-pause per _autonomous_pickup.md), теряя его работу.	2026-05-29 17:36:20 +03:00