774 commits

Author	SHA1	Message	Date
bot-backend	7e59c1e5b0	fix(#3194): hide_parameters=True на всех движках, include_local_variables=False у scheduler ... Ключ шифрования кук и сами куки уезжали в GlitchTip: сервисы сессий передают их bind-параметрами в pgp_sym_encrypt(:cookies_json, :key), а SQLAlchemy при ошибке печатает ВСЕ параметры в тексте StatementError. Правка на уровне движка (backend + tradein-mvp: db.py, auth_db.py, alembic/env.py) кроет все сайты вызова разом, включая четвёртую копию в scraper-kit и всё будущее. scheduler_main.py был единственным из трёх sentry_sdk.init без include_local_variables=False — процесс скрейпера, в кадрах лежат прокси-креды. НЕ закрывает: текст ошибки самого драйвера (Postgres DETAIL со значением) и сырые psycopg-подключения мимо движков — отдельный класс. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 14:53:41 +05:00
lekss361	84505b1e0b	chore(site-finder): удалить мёртвый код — 14 неиспользуемых символов (#3235)	2026-08-29 15:39:10 +00:00
bot-backend	25bebadca5	chore(deps): три места, где сборка не воспроизводится — лок-призрак, глоб и неприпинованный сайдкар ... Ничего не апгрейдит. Убирает три способа собрать образ не тем, что в репозитории. 1. tradein-mvp/backend/uv.lock — удалён (файл был untracked, в .gitignore с рождения). Мера — uv-workspace, сборка берёт КОРНЕВОЙ tradein-mvp/uv.lock (`context: ./tradein-mvp`, `COPY pyproject.toml uv.lock ./` + `uv sync --frozen`). Лок, созданный `uv lock` из backend/, не читает никто, и он тихо разошёлся с рабочим: на 2026-08-29 в нём pillow 12.2.0, starlette 1.0.1, python-multipart 0.0.29, pydantic-settings 2.14.1, weasyprint 68.1 — пять пакетов с открытыми advisory, которых в реальной сборке Меры нет вообще. Именно он подмешал пять фантомных строк в OSV-скан этой серии. Строка .gitignore остаётся (второй лок не нужен), но теперь с объяснением почему — иначе следующий читатель снимет ignore и закоммитит призрак. 2. backend/Dockerfile — `COPY pyproject.toml uv.lock* ./` + `if [ -f uv.lock ]; then uv sync --frozen ...; else uv sync ...; fi` → без глоба и без фолбэка. Глоб + фолбэк означали: пропал лок — сборка не падает, а молча переключается на резолв «свежайшее из диапазонов pyproject». Образ собрался бы с версиями, которых никто не видел ни в одном PR. Теперь пропажа лока роняет COPY. 3. tradein-mvp/browser/Dockerfile — `pip install "camoufox[geoip]" aiohttp` без единого пина. У сайдкара нет лока вообще, так что любая пересборка (в том числе на несвязанном коммите) тянула свежайший camoufox, а с ним другой playwright — под который НЕ написан sed-патч coreBundle.js в том же файле. Запинено по факту прод-контейнера tradein-browser: camoufox 0.5.5, playwright 1.60.0, aiohttp 3.14.3. playwright явно, хотя и транзитивный (camoufox 0.5.5 → playwright<1.61): патч завязан на конкретную сборку драйвера. Там же переписан комментарий «Апгрейд playwright невозможен — camoufox 0.4.11 pinned»: неверны обе половины. camoufox не был запинен ни на что, а 0.4.11 в проде не стоит с неизвестно каких пор — контейнер сейчас несёт 0.5.5 и playwright 1.60.0. Версии сняты с живого прод-контейнера, наличие на PyPI проверено.	2026-08-29 14:01:14 +03:00
bot-backend	e059e41f5f	fix(deps/site-finder): 53 advisory в backend/uv.lock — точечный апгрейд восьми пакетов ... Прогон всех локов через OSV batch API (2026-08-29) показал: уязвимые версии есть только в backend/uv.lock. Корневой лок «Меры» (tradein-mvp/uv.lock, из которого и собирается её образ) чист полностью — ноль находок. Было 8 пакетов / 53 advisory, стало 0. Проверено повторным прогоном OSV по получившемуся локу. pillow 12.2.0 -> 12.3.0 26 advisory, среди них heap OOB write в Image.paste/crop и ImageFilter.RankFilter; Image.open у нас на внешнем входе (загрузка фото) starlette 1.0.0 -> 1.6.0 10 advisory, в т.ч. обход лимитов request.form() cryptography 47.0.0 -> 50.0.1 7 advisory; транзитив pdfminer-six urllib3 2.6.3 -> 2.7.0 4 advisory; обход защиты от decompression-bomb weasyprint 68.1 -> 69.0 CSS injection via presentational hints idna 3.13 -> 3.19 2 advisory mako 1.3.11 -> 1.4.1 path traversal в TemplateLookup (Windows-only, у нас Linux — берём попутно) pydantic-settings 2.14.0 -> 2.15.0 1 advisory Апгрейд ТОЧЕЧНЫЙ (--upgrade-package на 8 имён), не общий --upgrade: спеки в pyproject все вида ">=" без верхней границы, и общий апгрейд затянул бы мажоры вроде redis 7->8 и numpy заодно. Диффом подтверждено: из 138 пакетов изменились ровно эти 8, прямые спеки в pyproject.toml не тронуты. Проверка совместимости локально: fastapi 0.136.1 поднимается на starlette 1.6.0, TestClient отвечает. weasyprint импортировать на Windows нельзя (нет GTK), его гоняет CI на Linux. NB: fastapi.testclient на starlette 1.6 предупреждает, что связка с httpx устарела в пользу httpx2 — это ворнинг, не отказ; отдельная задача.	2026-08-29 13:28:36 +03:00
bot-backend	192fdbfbf6	fix(ops/metrics): тема «метрики» задаётся дефолтом, а не ручным заведением секрета ... Разделение тем из #3163 зависело от шага «завести секрет руками». Шаг отказал сразу же: 27.08 два прогона деплоя подряд отработали зелёными, напечатали строку про откат — и тема «метрики» осталась пустой, а весь инфраструктурный поток продолжил идти в тему клиентских инцидентов. Номер темы форума секретом не является: в репозитории уже лежат домены, пути на хостах, имена контейнеров и внешние адреса. Ставим 245 значением по умолчанию прямо в деплое; переменная окружения по-прежнему перекрывает — переезд темы или другой чат решается ею, без правки кода. Откат на METRICS_TELEGRAM_TOPIC_ID убран намеренно и запрещён тестом. Он возвращал ровно то состояние, ради ухода от которого всё затевалось, и сообщал об этом строкой в логе прогона, которую никто не читает. Молчаливое «почти правильно» хуже явной поломки. Прогнано в обе стороны: с переменной — тема из окружения, без неё — 245. backend/tests/ops — 86 passed.	2026-08-27 22:28:52 +03:00
bot-backend	b90872b5d7	feat(ops/metrics): инфра-алерты уезжают в тему «метрики», клиенты остаются в «алертах» ... Форумная группа имеет три темы, но тема «метрики» была пуста: оба прямых получателя Alertmanager — telegram и telegram-heartbeat — брали топик из той же переменной METRICS_TELEGRAM_TOPIC_ID, что и сервис alert-ack. Развести их было нечем, и heartbeat вместе со всем инфраструктурным шумом падал в ленту клиентских инцидентов. Смешанные в одной теме, инфраструктура и клиентский инцидент не равны по срочности и приучают пролистывать обе. Вводится METRICS_TELEGRAM_INFRA_TOPIC_ID для прямых получателей Alertmanager. alert-ack и вебхук GlitchTip остаются на прежней переменной, тема поддержки не тронута. Пока новая переменная не задана, берётся старая — до этого момента поведение ровно прежнее, а не сломанное. Клиентская METRICS_TELEGRAM_TOPIC_LINE убрана целиком: после переезда обоих получателей на инфраструктурную строку шаблон её не содержит, а деплой продолжал бы её собирать и объявлять в envsubst. Тест, закрепляющий сборку такой строки, зеленел бы вечно и мешал бы её убрать. Проверено рендером, а не чтением: при заданной теме telegram и telegram-heartbeat дают 245, telegram-clients уходит вебхуком без темы; при незаданной — поля message_thread_id нет вовсе (пустое значение уронило бы Alertmanager целиком). Логика отката прогнана во всех трёх состояниях переменных. backend/tests/ops — 86 passed. Closes #3163	2026-08-27 21:50:51 +03:00
bot-backend	de940c7534	feat(ops): off-box копия рантайм-конфига — зашифрованной, иначе никак ... Четвёртый пункт приёмки #2203. В дампах есть колонки под pgp_sym_encrypt, ключ к ним лежит на самой машине и никуда не уезжает: потеря машины означает «дампы есть, расшифровать нечем». Ради этой связки шифрование в базе и заводилось. КУДА И ПОЧЕМУ ИМЕННО ТУДА. В тот же S3, отдельным префиксом env/, и только зашифрованным. Разобранные варианты: - рядом с дампами открытым — нельзя: ключ рядом с шифротекстом обнуляет шифрование, одна утечка доступа к бакету отдаёт и то и другое; - на соседний хост по SSH — потребовало бы завести доверие между машинами, которого нет (проверено: Permission denied (publickey)), то есть РАСШИРИТЬ периметр ровно тогда, когда #3075 его сужает; - отдельный бакет с отдельными ключами — правильнее всего, но требует новых учётных данных. Выбран единственный исполнимый без расширения доступа: шифротекст в S3, парольная фраза — вне S3. FAIL-CLOSED. Без фразы скрипт не выгружает файл открытым, а падает с явным сообщением и алертом. Молчаливая выгрузка ключа в бакет с дампами хуже отсутствия копии: создаёт ложное чувство защищённости. Фраза уходит через дескриптор, а не аргументом — иначе видна в ps любому пользователю машины. После шифрования файл проверяется обратной расшифровкой: без этого можно годами возить нечитаемый мусор и узнать в тот момент, когда он понадобился. Прогон на хосте 27.08 (подставной исходник, боевой не трогался): без фразы → код 1, файлов создано 0 с фразой → «Зашифровано и проверено расшифровкой», 110 байт своей фразой читается, чужой — нет ОДИН ШАГ ЗА ВЛАДЕЛЬЦЕМ, и он неустраним: фраза обязана жить там, где переживёт смерть машины, иначе копия бесполезна — расшифровать будет нечем. Сгенерировать её здесь и оставить на хосте нельзя по построению. Инструкция — в шапке скрипта. Пять тестов сторожат ровно те свойства, ради которых всё сделано. Прогон: 85 ops-тестов зелёные, ruff чист. Refs #2203	2026-08-27 16:32:27 +03:00
bot-backend	b746134976	fix(ops/metrics): postgres-exporter печатал пароль БД в лог при каждой ошибке ... Версия v0.16.0 при КАЖДОЙ неудаче сбора печатала полный DSN вместе с паролем: msg="error scraping dsn" err="queryNamespaceMappings returned 1 errors" dsn="postgresql://<роль>:<ПАРОЛЬ>@<хост>:5432/<база>?sslmode=disable" Строки уходят в Loki — около 210 в сутки с двух хостов, при ретенции 30 дней это тысячи паролей в хранилище логов (#3114). Проверял опытом, а не документацией. Стенд на скретч-контейнерах: чистый постгрес, роль без прав, тот же queries.yml что на проде — то есть ровно та ошибка, что случалась в бою. v0.16.0 → строк с паролем: 1 v0.18.0 → строк с паролем: 0 ОБХОДНОЙ ПУТЬ ИЗ ISSUE НЕ РАБОТАЕТ, и это важнее самой правки. Предлагалось передавать параметры через DATA_SOURCE_URI + DATA_SOURCE_USER + DATA_SOURCE_PASS вместо единой строки — «тогда в лог попадать нечему». Проверил на том же стенде: экспортер собирает DSN внутри и печатает его целиком точно так же, 1 строка с паролем. Реализация этого варианта была бы работой вхолостую при полном ощущении, что дыра закрыта. Паритет метрик проверен там же: все пять пользовательских запросов из queries.yml отдаются обеими версиями одинаково (PG_EXPORTER_EXTEND_QUERY_PATH в v0.18 работает), v0.18 добавляет три встроенные метрики и не теряет ни одной. Два теста сторожат нижнюю границу версии на всех трёх экспортерах. Прогон: 80 ops-тестов зелёные, ruff чист. Refs #3114	2026-08-27 15:55:24 +03:00
bot-backend	5ea05cffa6	fix(ops/metrics): правки конфига Alertmanager молча не доезжали до контейнера ... Пойман на проде 27.08 сразу после мержа #3136. На диске лежал новый конфиг — `webhook_configs` на сервис кнопки подтверждения, — `amtool check-config` его одобрил, деплой зелёный. А контейнер продолжал слать алерты напрямую: на диске: webhook_configs: url http://alert-ack:8080/alertmanager в контейнере: telegram_configs: Конфиг подключён бинд-маунтом ФАЙЛА, а рендер делает `rm` и создаёт файл заново — иначе не перезаписать: после chown он принадлежит 65534 с правами 600, а каталог принадлежит деплой-пользователю. `rm` + создание даёт НОВЫЙ инод, тогда как открытый дескриптор внутри работающего контейнера продолжает смотреть на прежний, уже удалённый. `up -d` контейнер не трогает: он сравнивает описание сервиса, а содержимое бинд-маунта в сравнение не входит. Отказ беззвучный — ни одного красного признака нигде. Значит и все прежние правки маршрутизации применялись лишь тогда, когда контейнер пересоздавался по совпадению. Перезагрузка по SIGHUP/API не лечит: она перечитывает тот же открытый инод. Лечит только пересоздание контейнера — его и добавляю, под флагом, который выставляется ПОСЛЕ успешной проверки конфига. Порядок важен: при обратном битый конфиг убивал бы работающий Alertmanager вместо того, чтобы оставить прежний работать. Прод уже приведён в соответствие вручную — контейнер пересоздан, маршрут клиентских инцидентов теперь идёт через кнопку. Эта правка нужна, чтобы следующая правка конфига доехала сама. Три теста: пересоздание есть, оно закрыто проверкой флага (безусловное рвало бы доставку на каждом деплое метрик), флаг выставляется после проверки. Прогон: 78 ops-тестов зелёные, ruff чист.	2026-08-27 15:10:23 +03:00
bot-backend	4e8daff675	fix(tests): убрать директивы noqa на неактивное правило ... `SLF001` (обращение к приватному члену) в конфиге ruff не включён, поэтому `# noqa: SLF001` — подавление того, что и так не проверяется. Ruff ловит это правилом RUF100 и валит проверку. Тест намеренно лезет в приватные `_tg`, `_PENDING`, `_send_alert`: подмена единственного шва до сети — и есть смысл этих тестов. Пояснение, которое стояло после директивы, сохранено обычным комментарием.	2026-08-27 14:32:34 +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
lekss361	0f09c47418	Merge pull request 'fix(ops): оповещения уходят в тему «алерты», а не в переговорку (#2203)' (#3129) from fix/2203-notify-topic into main	2026-08-27 10:50:55 +00:00
bot-backend	6446a8cdf5	fix(tests): ruff E741 — однобуквенное имя переменной в разборе скрипта	2026-08-27 13:16:26 +03:00
bot-backend	8945ea5d04	fix(ops): оповещения уходят в тему «алерты», а не в переговорку (#2203) ... Канал включили — и алерты бэкапов посыпались в ОБЩУЮ тему форума. В форуме Telegram адрес сообщения это пара «чат + тема»: без message_thread_id всё попадает в General, причём без единой ошибки. sendMessage возвращает 200, доставка «успешна», просто не туда. Отказ того же класса, что и всё остальное сегодня: зелено везде, а человек, которому адресован алерт, его не видит. Оба отправителя (ops/lib-backup.sh и ops/uptime-healthcheck.sh) получили условную подстановку ${TELEGRAM_TOPIC_ID:+-d "message_thread_id=..."}. Условная намеренно: пустой message_thread_id= Telegram отвергает вместе со всем сообщением, а молчащий алерт хуже алерта не в той теме. Нет переменной — нет параметра, поведение прежнее бит в бит. Тест ИСПОЛНЯЕТ настоящий notify(), извлечённый из файла построчно, подсовывая подставной curl и проверяя, что реально ушло бы в сеть. Проверять подстроку в файле бессмысленно: она может стоять в мёртвой ветке. Копировать функцию в тест — тоже: копия разойдётся с оригиналом на первой правке. Сорсить файл целиком нельзя: у uptime-healthcheck.sh нет guard'а по BASH_SOURCE, и сорсинг запустил бы настоящие сетевые проверки.	2026-08-27 13:12:10 +03:00
bot-backend	6f120c6605	feat(observability): клиентский инцидент зовёт дежурного поимённо + чинит сломанное продолжение команды (#3078) ... Две вещи, вторая — исправление собственной ошибки из #3127. ## Дежурного зовут по имени 27.08 продукты лежали 10 часов, и в канале «диск занят на 86 %» и «клиенты не могут открыть сайт» выглядели одинаково. Появился отдельный маршрут: severity=critical И host=apps, то есть критично на ПРОДУКТОВОЙ машине — значит людям недоступна МЕРА и Site Finder, а не «где-то в инфраструктуре тесно». У такого сообщения другой текст (🚨 КЛИЕНТЫ ЗАТРОНУТЫ), упоминание дежурного и repeat_interval 30 минут против 3 часов у прочего критичного: пока инцидент не погашен, напоминание должно быть неудобным. Сужение по host=apps существенно. Без него дежурного звали бы на каждую инфраструктурную мелочь, и тег перестал бы что-либо значить за неделю. Сам аккаунт в репозиторий не попадает — берётся из METRICS_TELEGRAM_ONCALL. Дежурный меняется, конфиг в git — нет. Пустая переменная = сообщение без тега, поведение не ломается. ## Починка: комментарий внутри продолжения команды В #3127 блок rm -f вместе с комментарием встал МЕЖДУ строками, каждая из которых заканчивалась обратным слешем. Строки склеиваются, и весь вызов envsubst уехал в комментарий — конфиг Alertmanager перестал бы рендериться вовсе, при полностью зелёном деплое. Синтаксически это корректный шелл, bash -n такое не ловит, а в диффе не видно: строки выглядят как отдельные. Поэтому проверка структурная и применяется ко ВСЕМ shell-блокам workflow, а не только к месту ожога.	2026-08-27 13:05:32 +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	c093eaafe5	fix(observability): пароли не уезжают в Loki — скруббер учётных данных (#3114) ... postgres_exporter при неудачном скрейпе печатает полный DSN вместе с паролем. Замер по Loki за сутки: 104 такие строки на инфра-хосте и 106 на продуктовом. При ретенции 30 дней это порядка 6000 строк с паролями БД в хранилище, доступ к которому даёт вход в Grafana - причём внешний basic_auth с витрины сегодня же снят (#3113). Проверено экспериментом, а не предположено. Напрашивалось передать пароль отдельно от строки подключения (DATA_SOURCE_URI + DATA_SOURCE_USER + DATA_SOURCE_PASS_FILE). Прогон на скретч-контейнерах с настоящим файлом запросов показал: НЕ помогает - экспортер собирает строку сам и логирует её целиком. Первые три попытки воспроизведения были неинформативны (контейнер падал сразу; скрейпа не было; не подключён файл кастомных запросов) - утечка воспроизводится только при неудачном скрейпе с нашим queries.yml. Стало: ступень loki.process между источником журнала и loki.write, маскирует пароль в любом URL вида scheme://user:pass@host. Пользователь и адрес остаются - без них строка ошибки перестаёт годиться для диагностики. Ровно одна группа захвата: Alloy заменяет содержимое групп, вторая затёрла бы имя пользователя. Это защита в глубину, а не замена причине. Конкретно эта ошибка уходит грантом pg_monitor (запрос pg_wal_bytes в нашем queries.yml требует pg_ls_waldir) - это боевая БД и остаётся за владельцем. Скруббер же ловит любой пароль в URL, включая компоненты, о которых мы ещё не знаем. Регулярка без экранирования намеренно: Alloy не принимает \s в строке (unknown escape sequence), поэтому класс задан явным пробелом. Оба конфига прогнаны через `alloy fmt` образом grafana/alloy:v1.6.1 - синтаксис ok. Тесты (8) берут выражение ИЗ КОНФИГА и применяют к настоящей строке из прода: пароль исчезает; пользователь и адрес остаются; обычные URL и почтовые адреса не портятся; журнал направлен в скруббер, а не мимо него. Фальсификация: на исходных конфигах краснеют все 8. tests/ops целиком - 43 passed.	2026-08-26 15:50:57 +03:00
bot-backend	5b7ef161e3	feat(observability): алерты адресуются в топик форумной группы (#3078) ... Бот, которым шлются тревоги, — тот же, что пересылает сообщения поддержки, а его чат форумный. Без message_thread_id Alertmanager кладёт тревоги в общую тему, вперемешку с клиентской перепиской. Поле поддерживается: проверено amtool check-config на том же образе, что поднимается в проде (prom/alertmanager:v0.28.0). Схема Alertmanager строгая и неизвестные поля отвергает, так что успешная проверка означает именно поддержку, а не молчаливое игнорирование. Подставляется ЦЕЛАЯ СТРОКА, а не значение: envsubst не умеет условий, и при шаблоне вида `message_thread_id: ${TOPIC_ID}` незаданный топик дал бы `message_thread_id:` без значения. Это не деградация - Alertmanager с таким конфигом не стартует вовсе, то есть алертинг исчезает целиком. Деплой формирует либо всю строку с отступом, либо пустую. Топик необязателен: без него поле отсутствует, алерты уходят в общую тему, поведение прежнее. Попутно добавлена проверка конфига через amtool ДО подъёма стека - по образцу `caddy validate` ниже в этом же файле. amtool берётся из того же образа, что и сам Alertmanager, иначе проверялась бы не та версия схемы. Битый конфиг теперь роняет деплой громко, а не выключает алертинг тихо. Тесты (4) рендерят шаблон обоими способами и разбирают результат как YAML - проверяется фактический конфиг, а не наличие нужных слов в тексте. Отдельно проверено, что переменная объявлена в списке envsubst: забыть её - значит оставить в конфиге литерал плейсхолдера. Фальсификация: на исходных файлах краснеют 3 из 4; проходит только тест, фиксирующий сохранённое поведение при незаданном топике. tests/ops целиком - 35 passed.	2026-08-26 14:10:56 +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
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	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	c7df2732bd	fix(ops): алерт не теряется от одного сетевого отказа (#3059) ... Путь Selectel-Telegram теряет соединения. Замер 26.08 с Poincare, 40 подключений к закреплённому (#3093) 149.154.167.220: успешно 37 из 40, отказов 3 (7.5%) - все TimeoutError время успешных: min 0.14s, медиана 0.15s, max 0.17s Отказы происходят на стадии ПОДКЛЮЧЕНИЯ - быстрые стабильные успехи на фоне редких таймаутов. Три остальных дата-центра Telegram с Selectel недостижимы вовсе, так что закрепление адреса потери убрать не может: запасного адреса нет. Бот это переживает своими ретраями (106 таймаутов за сутки, 97 лечатся первой же повторной попыткой), а вот алерты - нет. uptime-healthcheck.sh: был один curl и `|| log WARN` - каждый отказ терял уведомление целиком. Сторож, который не может дозваться, - худший вид самоскрывающейся поломки: чем хуже дела на проде, тем выше шанс, что о них не сообщат. Ирония в том, что ниже в этом же файле HTTP-проверки уже повторяются циклом: ретраили то, что измеряют, но не то, чем докладывают. lib-backup.sh: тоже один curl, но с падением в почту (#3070). Алерт не терялся, зато каждый транзиентный таймаут впустую сжигал последнее средство вместо простого переподключения. Стало: цикл из трёх попыток в обеих notify(). Не `curl --retry` - семантика --max-time при ретраях зависит от версии curl, а цикл даёт таймаут на КАЖДУЮ попытку и повторяет идиому, уже принятую в uptime-healthcheck.sh. Дубль вместо потери - осознанный размен: sendMessage не идемпотентен, но отказ случается ДО отправки запроса, так что повтор почти никогда не продублирует доставленное. Лишний алерт безвреден, пропущенный - нет. Тесты (backend/tests/ops/test_3059_alert_retry.py, 7 шт) исполняют РЕАЛЬНЫЕ notify(), извлечённые из обоих скриптов, с подставным curl, отказывающим заданное число раз, и считают фактическое число попыток. Фальсификация: на исходных скриптах краснеют 6 из 7. Проходит только test_backup_falls_back_to_mail_when_telegram_is_really_down - он фиксирует сохранённое поведение, а не регресс. Проверено: `bash -n` обоих скриптов (та же проверка, что в CI - shellcheck там нет); конструкция `[[ ]] && cmd` в конце тела цикла безопасна под `set -euo pipefail`, который стоит в uptime-healthcheck.sh:25 (проверено исполнением, не рассуждением); tests/ops целиком - 22 passed.	2026-08-26 10:02:46 +03:00
bot-backend	f2945b7157	fix(ci): деплой падает громко, если :latest отстаёт от головы по компоненту (#2950) (#3023)	2026-08-21 12:19:07 +00:00
bot-backend	cdf493f345	chore(format): нормализация под ruff 0.15.20 — 161 файл, только формат (#2864) (#3022)	2026-08-21 12:01:52 +00:00
bot-backend	1782dae0e2	chore(tooling): pre-commit, pyproject и uv.lock — один ruff 0.15.20 (#2864) (#3021)	2026-08-21 11:37:23 +00:00
bot-backend	ccf84b4adc	fix(best-layouts): avg_area_m2 = NULL вместо 0 при пустом окне сделок (#2867) (#3018)	2026-08-21 10:27:02 +00:00
bot-backend	9b54d64bd8	test(#2998): сторож партиций — герметично в схеме-песочнице, а не по живому проду ... (см. описание в PR #3014) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:33:57 +05:00
bot-backend	e6e5bd962c	fix(data): партиции rosreestr_deals на Q2–Q4 2026 + загрузчик доходит до файла (#2998) ... Задача формулировала «импорт каждый день рапортует done с total_seen=0». Проверка на проде показала другое: импорт исправен — ежедневно вычитывает все 96 974 строки FDW-источника и честно их пропускает (rows_fetched = rows_skipped = 96974), а `total_seen` — поле админ-витрины, не счётчик импорта. Источник gendesign.rosreestr_deals стоял на Q1 2026 (загружен 30.04), хотя Q2 2026 опубликован Росреестром 10.07 и poll заметил его 14.08 (available=1). Оба сторожа — poll и deals_freshness_monitor — сработали и семь событий ушли в GlitchTip, где 0 правил / 0 адресатов / 0 отправок. Корень, которого в задаче не было: rosreestr_deals партиционирована по period_start_date, партиции созданы списком в 01_schema «2024 Q3 — 2026 Q1», и ничто новые не создаёт. Загрузка Q2 21.08 упала: ERROR: no partition of relation "rosreestr_deals" found for row DETAIL: (period_start_date) = (2026-04-01) То есть даже оператор, запустив загрузчик по подсказке poll, получил бы отказ. Это и объясняет, почему poll сделан «только сообщить». Что сделано: • миграция 193 — партиции Q2, Q3, Q4 2026 с запасом, идемпотентно, с lock_timeout; индексы наследуются от родителя (проверено: 4 на 2026q2); • JOBS загрузчика — 2026Q2–Q4 (квартал без CSV честно SKIP); • ловушка set -e в загрузчике: resolve_csv сигналит «файла нет» кодом 1, и первый же квартал без CSV молча ронял ВЕСЬ прогон до строки SKIP — на проде с одним Q2-файлом скрипт завершался rc=0, не напечатав ни строки. `|| true` на вызове; после правки боевой прогон на VPS: 12 кварталов, 2026Q2 «уже загружен (741874 строк)», остальные SKIP, rc=0; • тест-сторож горизонта: партиция обязана существовать на последний публикуемый квартал (+20 дней лага после конца квартала; Q2 2026 вышел 10.07) и на следующий — чтобы предупреждение приходило за квартал до отказа, а не в день публикации. Читает pg_inherits живого Postgres. Красная сторона воспроизводима на проде, где миграция уже применена: DETACH партиции в откатываемой транзакции → головная краснеет по значению («нет партиции на квартал 2026-04-01»), откат возвращает партицию (проверено: 12 партиций после теста). Без БД — skip с причиной, в allowlist; календарный тест идёт везде. Сам Q2 загружен на прод по штатному пути: 741 874 строки в rosreestr_deals (ЕКБ-фильтр 13 654), import-rosreestr.sh → tradein.deals +11 649 сделок, max(deal_date) 2026-01-01 → 2026-04-01. deals_freshness_monitor на следующем тике: alert 0, latest_quarter 2. pytest backend/tests/sql — 55 passed (через туннель к проду). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 12:48:28 +05:00
bot-backend	70f3c0a88a	fix(ops): проверка трейлера дампа падала на grep — ведущие -- принимались за опции (#2203) ... verify_dump_integrity() в ops/backup.sh и tradein-mvp/deploy/backup-tradein-db.sh делала `grep -qF "$trailer"`, где $trailer = "-- PostgreSQL database dump complete". Ведущие -- в аргументе grep трактует как конец опций/флаг, без разделителя команда падает: `grep: unrecognized option '-- PostgreSQL...'`. Проверка из-за этого ВСЕГДА возвращала "трейлера нет" — не потому что дамп оборван, а потому что сама проверка не могла выполниться. Вызывающий код удалял только что созданный валидный дамп и завершался с ошибкой; ретеншен не успевал отработать (ранний exit) — свежие бэкапы не создавались никогда, старые копии оставались молча. Воспроизведено вручную на проде: bash /opt/gendesign/tradein-mvp/deploy/backup-tradein-db.sh удалил свежий дамп с сообщением "дамп оборван?". Фикс: `grep -qF -- "$trailer"` — `--` явно завершает список опций grep. Регрессионный тест (backend/tests/ops/test_2203_backup_trailer_grep_dashdash.py) исполняет РЕАЛЬНУЮ verify_dump_integrity() из обоих скриптов на настоящем gzip-потоке через gunzip|tail|grep — не читает исходник текстом. Проверено локально: падает на добаговой версии с тем же "unrecognized option", зелен на исправленной.	2026-08-20 23:38:45 +03:00
bot-backend	416bb4ed89	fix(ptica): «геологический риск» больше не выводится из шума (#2934) ... `risks.geology_risk_label` назывался геологическим риском, а вычислялся так: high — если подтопление medium — если шум ≥ 65 дБ low — иначе Геологии в нём не было ни одного бита. При этом `cad_risk_zones` пуста (0 строк, писателя нет — #2934 п.6), поэтому подтопление приходило только из OSM-прокси «река ближе 200 м». На тихом участке без реки поле ВСЕГДА говорило «low» — зелёный вердикт, ни разу не подкреплённый проверкой геологии. Поле убрано, а не переименовано: соседний блок `geology` честно отдаёт `data_available: false`, когда данных нет. Замена не нужна. Удаление поля из публичного ответа обосновано замером, а не словом: потребителей нет ни в backend, ни во фронте, ни в §19-allowlist чата, ни в экспортёрах; в схеме `risks: dict[str, Any]`, поэтому OpenAPI не меняется. На это поставлен отдельный тест, который перечитывает дерево исходников — иначе обоснование держалось бы на моём слове. Двусторонне: против origin/main три теста красные («метка всё ещё выдаётся», «шум по-прежнему участвует в риск-блоке», «поле где-то ещё читается»). Контроли зелёные с обеих сторон: измеренный `noise_score` остаётся на месте, `flood_zone` тоже (его судьба — отдельный пункт задачи). Контроль подмены отдельно: тест запрещает словесные градации риска в блоке, иначе «починка» переименованием оставила бы тот же обман. Проверка потребителей отличает комментарий от использования — иначе она краснеет на собственном объяснении правки (на это я наступал трижды за сутки, см. соседние PR). pytest backend/tests/api/ — 377 passed, 1 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 00:43:20 +05:00
bot-backend	5cd3502493	fix(ptica): три места, где код делал не то, что говорил (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 19:18:00 +00:00
bot-backend	b12f506953	docs(ptica): две докстроки обещали то, чего в коде нет (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 19:08:32 +00:00
bot-backend	f227768a53	fix(ptica): три места, где код делал не то, что говорил (#2464) ... 1. `load_water_reserves_from_docx` собирал `result` с ключом `period`, печатал ПОЛНЫЙ словарь в лог, а возвращал `{k: v for … if isinstance(v, int)}` — период это строка или None, поэтому выбрасывался всегда. По логам казалось, что период отдаётся; вызывающий не получал его ни разу. Фильтр стоял ради аннотации `dict[str, int]` и ничего не защищал: соседняя ветка `load_water_reserves` кладёт в тот же словарь `{"error": str(...)}`, а единственный потребитель — задача `sync_water_reserves` — результат логирует и возвращает как есть. Период полезен: без него «загружено 42 записи» не отличить от прошлогодних. Аннотация исправлена, иначе следующий проход mypy вернул бы фильтр обратно — на это поставлен отдельный тест. 2. `get_sqlite_info` — TOCTOU: `p.exists()`, затем незащищённый `p.stat()`. try/except покрывал только `sqlite3.connect` ниже, поэтому OSError из stat улетал наружу и превращал диагностическую функцию в источник отказа. Файл между проверками реально исчезает — его переписывает выгрузка Объектива. Теперь отдаём то, что успели узнать, с ключом `stat_error`. 3. `place_program` — предупреждение «участок мал» печатало КАТАЛОЖНЫЕ `house.footprint_*`, хотя ставили по `fp_w`/`fp_d`. При переопределённом в программе габарите сообщение называло размер, которым никто не пытался ставить, и уводило от причины. Двусторонне: против origin/main четыре теста красные с конкретными значениями («период выброшен из ответа: {'records': 1, 'inserted': 1, 'updated': 0}», «аннотация всё ещё требует только int: dict[str, int]»). Контроли зелёные с обеих сторон: отсутствующий файл по-прежнему даёт exists=False без ошибки; `fp_w`/`fp_d` — действительно те размеры, которыми ставят (иначе первый тест сверял бы имена, а не смысл). pytest backend/tests/services/ — 3207 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 23:59:02 +05:00
bot-backend	c979cf886a	fix(ptica): подпись сетевого обременения называет все виды, а не первый (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 18:53:32 +00:00
bot-backend	c3c8674b3c	docs(ptica): две докстроки обещали то, чего в коде нет (#2464) ... 1. `QuarterDump` (nspd_client): «Default = только core, чтобы не сжигать rate-limit на 17 запросов». Фактический дефолт `search_by_quarter` — `include_zouit=True`, то есть 5 ЗОУИТ-слоёв входят в дефолтный вызов. Числа 17 тоже нет: territorial_zones/red_lines/engineering и все ЗОУИТ идут через grid-walk при grid_n=7, по 49 запросов КАЖДЫЙ — дефолтный дамп это сотни запросов. Экономит rate-limit только include_risks=False. Докстрока самого метода 640 строками ниже говорит верно («Default True») — правильный образец лежал рядом с дефектом. 2. `find_active_on_demand_job` (cadastre_fetch): «Если в БД есть FAILED on-demand за последние 60 секунд — тоже None». В SQL нет ни слова 'failed', ни какого-либо временного фильтра. Обещание вдвойне вредно: подразумевало, что неуспешная джоба СТАРШЕ минуты вернётся как активная (не вернётся), и отправляло отлаживающего искать окно, которого нет. Гейты сверяют утверждение докстроки с кодом, а не читаемость текста: обещание «только core» требует `include_zouit=False` в сигнатуре; обещание минутного окна требует временного фильтра в теле. Двусторонне: против origin/main три гейта красные с конкретными сообщениями. Контроли зелёные с обеих сторон — характеризующий фиксирует фактические три статуса в SQL, а test_docstrings_state_the_actual_behaviour ловит «починку» через вычёркивание неудобной фразы. Два подводных камня, на которые наступил и оставил защиту: - гейт ищет обещание по тексту, поэтому старые формулировки в докстроках ПЕРЕСКАЗАНЫ, а не процитированы — иначе он не отличает цитату от утверждения (оговорено прямо в тексте докстроки); - тело функции нельзя брать как последний кусок разбиения по тройным кавычкам: SQL сам в них обёрнут, и проверка шла бы по огрызку после запроса. Из-за этого один гейт проходил по случайности. Вынесен хелпер `_body`. pytest backend/tests/services/ — 3199 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 23:43:40 +05:00
bot-backend	9810a946a6	fix(ptica): невозможные параметры регламента не превращаются в деньги (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 18:39:09 +00:00
bot-backend	b1dc5d5507	fix(ptica): подпись сетевого обременения называет все виды, а не первый (#2464) ... `cad_utility_label` брался от ПЕРВОГО overlap'а с распознанным `network_kind`, а покрытие агрегировалось по ВСЕМУ bucket'у. Участок под двумя видами охранных зон получал в отчёте конкретную причину, дающую малую часть площади: «Сетевое обременение (теплоснабжение) покрывает 74% участка» ← теплоснабжение даёт 10%, остальные 64% — инженерные коммуникации Это не редкость. Прод 20.08.2026: 316 пересечений охранных зон РАЗНЫХ видов, 155 зон вовлечено; самая частая пара — «тепловых сетей» × «инженерных коммуникаций» (296 из 316). Теперь копятся ВСЕ различённые виды и называются через запятую; множественное число, когда их больше одного. Покрытие — их объединение, и подпись это отражает. Заодно снята зависимость от порядка: подпись бралась от первого overlap'а, а он определяется `ORDER BY reg_numb_border, id`, который к покрытию отношения не имеет. Виды сортируются. Проверка попутно опровергла ДОВОД пункта эпика. Пункт говорит о смешении сетевых зон с keyword-совпадениями без network_kind. На проде таких ноль: из 3493 строк cad_zouit — 103 СЗЗ-предупреждения, 1936 с распознанной сетью, 1454 generic warning, и НИ ОДНОЙ «только по ключевому слову» (classify_network_zone уже покрывает все встречающиеся шаблоны). Вывод пункта — «конкретная причина приписывается чужой площади» — верен, но по другой причине: смешиваются РАЗНЫЕ ВИДЫ СЕТЕЙ, а не сети с keyword'ами. Двусторонне: против origin/main три теста красные, головной — с полной строкой, которую увидел бы пользователь. Контроли зелёные с обеих сторон: один вид сохраняет прежнюю формулировку в единственном числе, две зоны одного вида не дают дубль в подписи, area-gate не тронут (тонкая полоса остаётся warning). pytest test_gate_verdict + services/site_finder — 727 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 23:30:09 +05:00
bot-backend	3ecd7cffc8	fix(ptica): download_binary переживает транзиентный ответ, как и get_json (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 18:24:43 +00:00
bot-backend	06b0063c67	fix(ptica): невозможные параметры регламента не превращаются в деньги (#2464) ... `synthesize_teap_from_buildability` проверяла параметры только на `> 0`. Процент застройки 150 давал пятно БОЛЬШЕ участка (10 000 м² → 15 000 м²), а дальше — жилую площадь, число квартир и выручку: физически невозможные числа, поданные как обычные цифры финмодели. КСИТ 500 давал GFA 5 000 000 м² на гектаре. Параметры приходят из ПЗЗ-регламента (`zone_regulation_cache`) — внешние разобранные данные, то есть граница доверия. Невозможное значение ОТБРАСЫВАЕТСЯ, а не роняет расчёт: если рядом есть КСИТ, GFA считается по нему и остаётся верной. Лучше отсутствие параметра, чем неверный. Если вменяемых не осталось — None, и caller штатно показывает отсутствие финоценки с caveat, а не ноль. Границы взяты с запасом к реальным данным прода 20.08.2026 (33 строки zone_regulation_cache: pct 0..100, far 1..4, floors 0..5): pct ≤ 100, far ≤ 30, этажей ≤ 100 — сито против порчи разбора, а не норматив. ВТОРОЙ дефект, найденный этими же тестами и существовавший до правки: ветка «нет ни процента, ни этажности → пятно = GFA» неявно предполагает один этаж, и при КСИТ > 1 давала пятно больше участка (10 000 м² с far=2 → 20 000 м²). Добавлен физический инвариант «пятно ≤ участок» — не эвристика, а геометрия, и стоит он ОДИН раз после всех ветвей, чтобы держаться и для будущих способов оценки пятна. GFA при этом не меняется. Двусторонне: против origin/main четыре теста красные с конкретными невозможными значениями («пятно 15000.0 больше участка 10000.0», «GFA=5000000.0»). Восемь контролей зелёные с обеих сторон — среди них пять сочетаний (pct, far, floors), взятых ДОСЛОВНО с прода, и граница 100 % застройки, которая законна и на проде есть. pytest test_parcel_financial + services/generative + новый файл — 185 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 23:14:38 +05:00
bot-backend	0185889f72	fix(ptica): ключ gisogd_permits — id документа на портале, а не (группа, номер) (#2986) ... Закрывает #2986. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 18:03:48 +00:00
bot-backend	5aebc91f13	docs(ptica): докстрока не обещает защиты, которой нет, и не шлёт на мёртвый хост (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 17:58:20 +00:00
bot-backend	f72a08eb80	fix(ptica): download_binary переживает транзиентный ответ, как и get_json (#2464) ... Обе функции ходят через один браузерный контекст, под один и тот же WAF. `get_json` держит до пяти попыток с экспоненциальным backoff на 429/5xx/0, а `download_binary` не имел ретраев вовсе: один 429 ронял загрузку картинки насовсем, и вызывающий (`download_plan_image`, `download_photos`) писал в лог «не удалось» — неотличимо от «файла нет». Правильный образец лежал в этом же классе, двадцатью строками выше. Непереходные коды (403, 404) поднимаются сразу, без ожидания: повтор их не изменит, а лишний стук под WAF вредит. Разбор статуса вынесен ЗА семафор — sleep не должен держать слот. Двусторонне: против origin/main транзиентные тесты красные с конкретным значением («вместо байтов получили RuntimeError('binary http 429…'); попыток=1»), ни одного ImportError/TypeError. Контроли зелёные с обеих сторон: 403 и 404 не повторяются, исчерпание попыток даёт честную ошибку, а не пустые байты, успех с первой попытки не порождает лишних запросов. Отдельный контроль на паузы: без него «ретраит» и «долбит без пауз» неотличимы в тесте, а под WAF разница между ними решающая — проверяется, что задержки растут как 1, 2 секунды. pytest backend/tests/services/scrapers/ — 340 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:57:14 +05:00
bot-backend	9e04086daf	chore(ptica): перенумеровать миграцию 191 → 192 (#2986) ... Номер 191 занят PR #2984 (backfill act_date), который уходит в main раньше. Обе ветки прошли CI со своим 191 — проверка идёт по голове ветки и о занятости номера соседом узнать не может. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:41:27 +05:00
bot-backend	7d5ca247ca	fix(ptica): ключ gisogd_permits — id документа на портале, а не (группа, номер) (#2986) ... `UNIQUE (doc_group, doc_num)` вводился, чтобы склеивать ОДИН документ, пришедший из двух схем портала. Замер 20.08.2026 показал, что задача, ради которой ключ введён, почти отсутствует, а побочный эффект огромен: docNum у ГИСОГД НЕ уникален — разрешение и изменения к нему носят один номер. группа документов различных key различных docNum схлопывается DocRS 6098 6096 4305 1793 DocRV 5419 5415 4969 450 DocIZ 548 547 393 155 общих docNum между схемами (DocRS): 2 ← ради этого ключ и вводился общих key между схемами (DocRS): 2 ← те же два На проде 9182 строки против 12 065 документов на портале — нет 23.9 % реестра. Пример 66-06-06-2026: портал отдаёт два документа (key …719586 — само разрешение, key …752293 — изменения к нему), а UPSERT с предпочтением позднего date_reg оставлял только изменение. Так вытеснено 598 из 4320 строк РНС (13.8 %) — в §6 на месте разрешения показывается изменение к нему, без признака подмены. Ключ стал `UNIQUE (source_key)`: разделяет разрешение и изменения (разные key) и по-прежнему склеивает настоящие межсхемные дубли (у них key ОБЩИЙ — ровно 7 записей по всем группам). Дедуп перед сменой не нужен: source_key на проде уже уникален (9182 из 9182, NOT NULL). Заодно группа DocIZ добавлена в GROUP_CODE — её не было вовсе, 548 документов не грузились. CHECK расширен значением 'IZ'. §6 сужена до РНС/РВЭ ЯВНО: агрегат обещает total_count = rs_count + rv_count, а строки 'IZ' попадали бы в total и ни в один счётчик. Показывать ли изменения отдельной строкой — вопрос продуктовый (#2986); до его решения сужение стоит в запросе, а не держится на том, что таких строк «пока нет». Проверки: - два гейта на лоадер (GROUP_CODE и цель ON CONFLICT) — БЕЗ базы, двусторонние: на origin/main дают конкретные неверные значения ({'DocRS','DocRV'} и старый ON CONFLICT в тексте запроса); - гейт на §6 и контроль инварианта total = rs + rv на данных — красные на origin/main; - герметичная репетиция миграции на временной копии: со старым ключом разрешение и изменение схлопываются в одну строку (и остаётся именно изменение — как на проде), после миграции живут раздельно; межсхемный дубль по-прежнему склеивается; CHECK принимает 'IZ' и отвергает мусор. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:41:27 +05:00
bot-backend	3267120499	docs(ptica): докстрока не обещает защиты, которой нет, и не шлёт на мёртвый хост (#2464) ... `_page_contains_table` документировалась как «hint-только режим (оглавление, перекрёстные ссылки) даёт false positive и подавляется». Кода подавления в функции никогда не было — это `bool(cap.search(text))`. Обещание защиты, которой нет, опаснее её отсутствия: читающий не станет её добавлять. Замер уточнил и сам пункт эпика. Приведённый в нём пример перекрёстной ссылки «показатели приведены в таблице 12» регекс НЕ ловит: он требует именительное «Таблица N», поэтому «в таблице 12», «см. Таблицу 12», «табл. 12» дают False. Опасно ровно ОГЛАВЛЕНИЕ — там падеж тот же именительный, и «Таблица 11 Баланс территории ..... 34» неотличима от подписи. Это зафиксировано характеризующим тестом, чтобы следующая попытка подавления целилась в признаки оглавления (точки-выноски, номер страницы в конце), а не в падежи. Подавление здесь не реализовано сознательно: `ekb_ppt_tep` на проде пуста (0 строк), URL в `_SEED_DOCS` — заглушка, живых PDF нет. Эвристику отсева не на чем откалибровать, а правило, придуманное без образцов, ловит ровно те случаи, которые придумали вместе с ним. Отдельно исправлен комментарий сида: хост `gisogd.ekburg.ru`, названный там местом, «где лежит реальный URL», НЕ СУЩЕСТВУЕТ — DNS не резолвит его ни с рабочей машины, ни с прод-хоста (20.08.2026). Комментарий отправлял искать документ на портале, которого нет. Назван живой портал `gisogd66.midural.ru` и способ перечислить его разделы. Двусторонне: против origin/main два гейта красные — «докстрока обещает подавление, а в теле только поиск подстроки» и «комментарий сида не предупреждает, что хост мёртв». Характеризующие тесты зелёные с обеих сторон: они фиксируют фактическое поведение, а контроль test_docstring_names_the_actual_behaviour ловит «починку» через вычёркивание неудобной фразы. Гейт ищет обещание по слову, поэтому старая формулировка в докстроке пересказана, а не процитирована — иначе он не отличил бы цитату от утверждения; это оговорено прямо в тексте. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:36:23 +05:00
bot-backend	668f8c6ffb	fix(ptica): backfill act_date у 11 строк, куда уехала дата Генплана-2004 (#2464) ... заканчивается `ON CONFLICT DO NOTHING`, а не DO UPDATE, поэтому пятничный прогон (`0 7 * * fri`) существующие строки не перезапишет. Без этой миграции 11 строк остались бы с датой 2004 года навсегда — правка выглядела бы сделанной, а данные на проде остались бы кривыми. Замер прода 20.08.2026: 89adb28a… развязка Базовый/Комсомольская/Сибирский тракт 9 строк 9b9d9a99… улица Энергостроителей 2 строки обе группы: act_date = 2004-07-06 Верные даты не угаданы: оба PDF загружены с екатеринбург.рф и распознаны тем же трактом, что использует загрузчик (ocr_pdf_text), и в обоих настоящее основание — постановление Администрации города: № 1413 от 27.05.2022 и № 259 от 12.02.2020 соответственно. Сужение по doc_url обязательно: без него UPDATE задел бы любую строку с 06.07.2004, включая те, где эта дата настоящая. Миграция идемпотентна — условие `act_date = '2004-07-06'` при повторе не выполнится. Тест герметичный, прогоняет ТЕЛО миграции целиком на временной копии в прод-форме (9+2 целевых + 2 контрольных посторонних). Контроль-двойник `test_without_the_migration_rows_stay_wrong` обязателен: без него тест неотличим от «оно и так было правильно». Мутационно проверено сужение — снятие условия по doc_url роняет test_other_documents_with_same_date_are_untouched. pytest backend/tests/sql/test_2464_act_date_backfill.py — 6 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 22:11:35 +05:00
bot-backend	91a5207641	fix(ptica): лоты без площади — своя корзина, а не «<25 м²» (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 17:02:25 +00:00
bot-backend	508f2d6090	fix(ptica): act_date — дата акта об изъятии, а не первой попавшейся ссылки (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 16:43:27 +00:00
bot-backend	1b2a26bb9a	fix(ptica): лоты без площади — своя корзина, а не «<25 м²» (#2464) ... `_SUPPLY_ONLY_LOTS_SQL` раскладывал `area_pd IS NULL` в ту же корзину `'<25'`, что и настоящие студии. Замер прода 20.08.2026 (последний снапшот на физлот, premise_kind='квартира', не проданные): в продаже 181 353 без area_pd 11 557 (6.4 %) реально < 25 м² 7 013 Корзина «<25» состояла из неизвестного на 62 % и завышала долю мелких лотов в блоке «По предложению (без темпа продаж)». Зеркала у такого отображения не было: `layout_signature.area_bin` принимает float и NULL-ветки не имеет вовсе, а velocity-MV по площади не группирует — то есть `NULL → '<25'` было выдумкой, а не переносом чужого правила. Исключать такие лоты нельзя: они реально в продаже, и без них предложение занизилось бы на 6.4 %. Поэтому отдельная корзина «н/д». Медиана площади у неё выйдет NULL (PERCENTILE_CONT игнорирует NULL) — честно. Схема не меняется: area_bin остаётся str, OpenAPI прежний. Тест герметичный и прогоняет НАСТОЯЩИЙ SQL: временная таблица objective_lots затеняет боевую в пределах сессии, запрос берётся из модуля дословно, прод-данные не читаются. Двусторонне: против origin/main корзины распределяются как {'<25': 2, '25-40': 1, '40-60': 1} — конкретное неверное значение, ни одного TypeError/ImportError. Контроли (сумма лотов сохраняется, обычные корзины не меняются) зелёные с обеих сторон. pytest backend/tests/sql/ — 38 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 21:41:47 +05:00
bot-backend	46beeb4c13	fix(ptica): тип постановления — по первому упоминанию, а не по порядку проверок (#2464) ... Часть эпика #2464. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 16:28:26 +00:00