3 commits

Author	SHA1	Message	Date
bot-backend	4ee4d4b8e2	fix(tradein/privacy): нормализация телефона к каноническому РФ-виду при erasure (#2547) ... Follow-up к прошлому фиксу (regexp_replace \D): чистое удаление форматирования не закрывало разрыв, который сам ревьюер привёл в примере -- "+7 999 123-45-67" и "89991234567" после digit-stripping дают РАЗНЫЕ строки (79991234567 vs 89991234567, différent на первой цифре) -- классическая для РФ путаница 8/+7 trunk-префикса. _ru_phone_norm_sql(expr) добавляет второй шаг: если после digit-stripping получилось РОВНО 11 цифр с ведущей '8' -- заменить её на '7'. Точное тождество для российской нумерации, не эвристика (обсуждали: усечение до "последних 10 цифр" риск-скориальнее -- склеивает номера разных стран, удаление чужих данных хуже неудаления своих). Оба вызова (_PHONE_COLUMN_NORM_SQL / _PHONE_PARAM_NORM_SQL) строят SQL-структуру из статичных фрагментов (имя колонки / CAST(:phone AS text)) -- ни один телефон не попадает в текст запроса напрямую. Живая проверка (throwaway Postgres 16 в docker): лид "89991234567" находится и удаляется по запросу "+7 999 123-45-67" -- ровно кейс из ревью. Встроенный counterfactual в самом тесте доказывает, что чистый digit-strip (прошлая версия фикса) для этой пары находит 0 строк. Negative control: номер, отличающийся одной значащей цифрой, НЕ удаляется (защита от ложного совпадения = удаления чужих данных).	2026-08-06 19:59:34 +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	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