7 commits

Author	SHA1	Message	Date
bot-backend	cdf493f345	chore(format): нормализация под ruff 0.15.20 — 161 файл, только формат (#2864) (#3022)	2026-08-21 12:01:52 +00:00
bot-backend	48664dfe0e	fix(tradein/payments): pre-flight должен ловить аномалию, не штатное состояние (review PR #2754) ... Deep-review MEDIUM: предполётная проверка purge_expired_trade_in_data считала по базовому предикату без retain_until — здоровая оплаченная строка (retain_until проставлен, платёж есть) через сутки после продажи тоже попадала под счётчик, и джоба аварийно останавливалась на первой же честной продаже навсегда (вместе с ней — и 180-дневное удаление лидов, вызываемое из той же функции после этой проверки). - _PREFLIGHT_PAID_CANDIDATES_SQL: добавлен терм `retain_until IS NULL` — теперь считает только реальную аномалию (retain_until не проставлен, а платёж есть), а не штатное состояние. Докстринги функции/модуля поправлены под фактическое поведение. - Тест на неверный инвариант (`"retain_until" not in sql`) заменён на позитивный (`"retain_until IS NULL" in sql`) + добавлены live-DB тесты на оба случая из ревью (здоровая оплаченная строка не поднимает тревогу, джоба не блокируется). - privacy/page.tsx: константа "12 месяцев" вынесена в content.ts (PAID_REPORT_RETENTION_MONTHS) вместо литерала + расходящегося комментария; добавлен сверяющий тест (test_paid_retention_text_consistency.py) по образцу _CONSENT_TEXT_SNAPSHOT. Смягчена формулировка про автоматическое удаление — задача на проде выключена и ни разу не запускалась, текст теперь описывает установленный порядок, а не наблюдаемый факт. - Все 10 висячих ссылок на untracked `mera-pr-d-spec.md` (7 файлов) заменены на краткое изложение сути в комментарии + ссылку на PR #2754.	2026-08-06 22:49:09 +03:00
bot-backend	5ff06d25b4	feat(tradein/payments): оплаченный отчёт хранится год — retain_until и предохранители в задаче удаления ... Мина: purge_expired_trade_in_data (сейчас enabled=false) удаляет строки WHERE expires_at < NOW() AND created_by IS NULL — это ровно популяция будущих платящих физлиц (владелец продаёт отчёт за 150 руб., отчёт должен жить год на нашей стороне, а не 24ч). Первый прогон после запуска продаж безвозвратно снёс бы оплаченное. Делается ДО платёжного кода, которого в этом PR нет: - migration 234: колонка trade_in_estimates.retain_until (NULL = неоплачено, бэкенд-бита-в-бит не меняется) + частичный индекс под purge-предикат. - config.py: trade_in_paid_retention_days=365 (ENV) — единственный источник "12 месяцев" для будущей оферты/экрана/SQL продления. - Единый гейт чтения ESTIMATE_READABLE_SQL + estimate_readable() — раньше SQL-фильтр (404) и Python-проверка (410) в trade_in.py уже разошлись по тексту ответа; текст "estimate expired (24h TTL)" убран (стал бы ложью при годовом хранении). - purge_expired_trade_in_data: retain_until IS NULL (не < NOW() — оплаченное не удаляем в принципе) + NOT EXISTS(payments) как независимая страховка + pre-flight, который считает оплаченных кандидатов и падает в mark_failed ДО первого батча при ненулевом результате. - PDF: "Ссылка доступна до …" только при retain_until IS NOT NULL; "ДЕЙСТВИТЕЛЕН ДО" (expires_at, актуальность расчёта) не тронут. - Фронт: retain_until прокинут в mapper (validUntil остаётся на expires_at). - privacy-страница: убрано устаревшее "механизма удаления нет" (неправда после #2547), добавлен срок 12 месяцев для оплаченных отчётов. Ни строчки платёжного кода. expires_at, trade_in_estimate_retention_hours, _DELETE_EXPIRED_LEADS_SQL не тронуты.	2026-08-06 21:48:06 +03:00
bot-backend	881730bf20	fix(tradein/privacy): не удалять B2B-строки в purge + находить телефон в другом формате при erasure (#2547) ... Deep-review HIGH: purge_expired_trade_in_data удалял trade_in_estimates по expires_at без разбора B2B/B2C -- эта колонка TTL ссылки/PDF, а не срок хранения строки, и её единообразно проставляет каждой оценке estimator.py. Прод-аудит: 1040/1057 строк просрочены, 911 из них у пилотов (admin, kopylov, brusnika, praktika, pilottest, admintest, user1). DELETE теперь ограничен created_by IS NULL -- ровно анонимная B2C-популяция (129 строк). Докстринг миграции 231 переписан: явные цифры аудита, необратимость, чек-лист (свежий SELECT count + один supervised прогон) перед enable. Deep-review MEDIUM: erase_person_data сравнивал phone точным =, а lead.py сохраняет номер как прислали (без нормализации, намеренно) -- разное форматирование одного и того же номера не находилось, 0 строк удалялось, но ответ всё равно был 200 "данные удалены". Сравнение переведено на regexp_replace(x, '\D', '', 'g') с обеих сторон. Оба фикса проверены живьём (throwaway Postgres 16 в docker, вне обычного mock-only CI-лейна): без гварда пилотская строка удалялась вместе с анонимной; без нормализации разноформатный телефон не находился. С фиксами -- находит/не находит ровно как задумано. Добавлены self-skipping live-DB тесты (паттерн test_house_dedup_merge.py::_live_session) плюс статические SQL-guard тесты.	2026-08-06 19:49:13 +03:00
bot-backend	3ee99efaa4	chore(tradein/privacy): перенумерация 231 и merge main - коллизия префикса (#2547)	2026-08-06 19:10:27 +03:00
bot-backend	dccd2d4272	chore(tradein/privacy): перенумерация миграций и merge main - разблокировка PR (#2547) ... 192/193 -> 229/230: main занял 192_tradein_users_auth.sql и 193_tradein_users_seed.sql за время простоя PR. 228 зарезервирован открытым PR #2732 (228_payments.sql) - следующие реально свободные 229/230, порядок consent_proof -> retention сохранён. Правки ссылок на старые имена/префиксы: docstring-заголовки самих SQL-файлов, перекрёстная ссылка 229 -> 230 в комментарии-докстринге, комментарии migration 192/193 в lead.py / config.py / schemas/trade_in.py / purge_expired_trade_in_data.py, переменные и имена тестов в test_estimate_consent_gate.py / test_purge_expired_trade_in_data.py. (Оставлены нетронутыми ссылки на migration 192/193 в auth_session.py и test_team_api.py - это про другие, уже существующие на main миграции 192_tradein_users_auth.sql / 193_tradein_users_seed.sql, не про эту пару.)	2026-08-06 15:56:02 +03:00
bot-backend	5626d9e720	feat(mera/b2c): правовая рамка — согласие до сохранения, удаление по сроку и по запросу (этап 4 из 8) ... Три дефекта, каждый блокировал легальный публичный запуск. 1. Адрес физлица сохранялся в базу ДО любого согласия: согласие фиксировалось только на форме заявки, то есть ПОСЛЕ записи адреса. Для пилота с договором терпимо, для человека с улицы — нет. Проверка согласия поставлена первой строкой расчёта, до геокодирования и до обоих мест записи адреса. Хранение — колонками на самой оценке, 1:1 с уже работающим прецедентом для заявок (миграция 182): IP клиента, версия политики, дословный снимок текста. Отдельная таблица событий не заводилась: согласие даётся ровно на создание этой строки, и когда строка удаляется по сроку, исчезновение доказательства вместе с данными логично. Enforcement НЕ выводится из пустого created_by — первая версия так и делала и сломала 92 несвязанных теста оценщика, которые зовут расчёт без имени пользователя, проверяя ценовую логику. Вместо этого явный флаг, который выставляет единственный боевой вызывающий. B2B-поток не тронут: поле согласия опционально, иначе сломались бы пилоты, чей фронт его не шлёт. 2. Срок жизни оценки применялся только как фильтр при чтении — физического удаления не было ни в одной фоновой задаче, данные жили вечно вопреки декларированному сроку. Заведена задача удаления пачками с ограничением на прогон и коммитом после каждой пачки, идемпотентная. В расписании она ВЫКЛЮЧЕНА: это первая автоматическая задача, удаляющая персональные данные, и первый прогон должен быть под наблюдением. 3. Пути «удалите мои данные» не было. Добавлен сервис удаления и админская ручка. Ключи: имя пользователя, идентификатор оценки, телефон, чат в телеграме. Честно зафиксировано в коде: аноним без ссылки на оценку, без оставленного телефона и без обращения в поддержку неидентифицируем — удалить его данные без дополнительной идентификации нельзя. Отдельно: удаление чистит только копию в базе, зеркало переписки в телеграм-топике не удаляется ничем в кодовой базе, нужен ручной шаг. 4. Соответствие текста согласия на фронте и снимка на бэке держалось на комментарии. Теперь есть тест, который ловит расхождение. Сроки хранения вынесены в настройки. Значение для заявок предложено инженерно (типичный отраслевой диапазон), юридически обоснованный срок — за юристом, и это записано в коде. Тесты: 2775 passed.	2026-07-28 15:24:21 +03:00