14 commits

Author	SHA1	Message	Date
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	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	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	afa648b21f	fix(ptica): у пользователя не может быть двух дефолтных профилей весов (#2464) ... create_profile/update_profile делают «снять is_default у всех → поставить новому» двумя отдельными операторами. Между ними инвариант нарушен, и при одновременных запросах у пользователя может оказаться ДВА профиля с is_default=TRUE. А читающий _SELECT_DEFAULT брал LIMIT 1 БЕЗ ORDER BY — выбор молча перескакивал между ними от запроса к запросу. Два рубежа, а не один: миграция 190 — частичный уникальный индекс (user_id) WHERE is_default: два дефолта становятся невозможными на уровне БД; ORDER BY id — детерминированный выбор, если индекс когда-нибудь снимут. Соседние запросы этого файла тай-брейк по id уже имеют. Индекс не мешает штатной переустановке дефолта: порядок операторов в коде уже правильный (сначала снять у всех, потом поставить), поэтому в момент проверки дефолтов ноль. Это отдельно проверено тестом. Безопасность миграции: на проде нарушений нет — у admin один дефолт, у __system__ ноль, ни одного пользователя с двумя. Таблица в 4 строки, индексируется мгновенно. lock_timeout проставлен по #2752. Тест проверяет ПОВЕДЕНИЕ на живом Postgres: вторая установка дефолта отвергается базой. Плюс фальсификация — без индекса два дефолта вставляются молча; без неё зелёный тест неотличим от «оно и так не вставлялось». Плюс два контроля: переустановка дефолта работает, разные пользователи сохраняют свои. Тест про ORDER BY вынесен в tests/services/site_finder, а НЕ внесён в skip_allowlist: живой БД он не требует, и пропускаться вместе с DB-тестами ему незачем. Против origin/main он краснеет, показывая запрос без тай-брейка. Прогоны: без БД — 648 passed rc=0; с БД — 5 passed rc=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 16:58:48 +05:00
bot-backend	04f70b8da0	fix(ptica): land_reservation перестаёт копить дубли — 91% таблицы были копиями (#2464) (#2966)	2026-08-20 10:16:34 +00:00
bot-backend	53becb2e64	fix(ptica): выручка и сделки в KPI лидов названы по своему охвату (#2464) (#2963)	2026-08-20 09:44:14 +00:00
bot-backend	f7e8228550	fix(ptica): свежесть data-table источника считается по успешным строкам (#2956) (#2957)	2026-08-20 08:36:05 +00:00
bot-backend	2e20b6307b	fix(tradein): гейт номеров миграций берёт эталон из git, ручной манифест удалён ... _manifest_applied.txt по построению не мог покраснеть. Тест считал «новым» любой файл, которого нет в списке, а новые файлы от списка освобождены (докстринг test_manifest_covers_all_but_new_files: «НЕ требует, чтобы новый файл уже был в manifest»). Забытое имя и новая миграция PR для гейта — одно и то же, поэтому дрейф был не пропуском проверки, а её штатным исключением. Замер на main 2026-08-07: 15 имён не дописано, все четыре теста зелёные — через сутки после того, как #2692 догнал список руками. Список при этом был лишь копией того, что git и так знает: deploy-tradein.yml применяет КАЖДЫЙ data/sql/*.sql из main под ON_ERROR_STOP, то есть «файл доехал до main» и есть «имя закреплено на проде». Ведём эталон в git — и дрейфовать становится нечему. Кросс-ветковая дыра закрыта тем же ходом: номер нового файла сверяется с ПОЛНЫМ origin/main, а не с рабочим деревом, поэтому коллизия с миграцией, смерженной после ветвления, находится. Проверено на живом PR #2754 (234_trade_in_estimates_retain_until против 234_scrape_runs_ban_kind_unknown из main): старый гейт зелёный, новый красный. Удаление/переименование применённой миграции сверяется с ТОЧКОЙ ВЕТВЛЕНИЯ, а не с origin/main: иначе ветка недельной давности краснела бы за чужие миграции. Проверено — ветка от 2026-07-30 при +43 миграциях в main зелёная. CI: checkout переведён на fetch-depth 0 + отдельный fetch main. Этот Forgejo не публикует refs/pull/N/merge (1620 */head, ноль */merge), а на depth=1 нет ни origin/main, ни общего предка — без этого гейту не с чем сверять, и он намеренно красный, а не тихо пропущенный. Контракт сведён к одной формулировке — докстринг test_migration_numbering.py; шапка манифеста, правило 3, хвост манифеста и рецепт из .claude/rules удалены или заменены ссылкой. Заодно исправлен сам рецепт: `git ls-tree` без `-r` печатает каталог, а не файлы. Refs #2683	2026-08-07 14:35:28 +05:00
bot-backend	b5976c0cc9	feat(auth): роли и трёхзначное состояние доступа в БД auth [PR-2a/6] ... Схема под решения владельца от 2026-07-31 по эпику «единый вход». Python-кода нет, поведение прода не меняется — в БД auth пока никто не ходит. Развилка А закрыта в пользу ПОЛНОГО переезда: tradein_users (БД tradein) в итоге удаляется, auth.users становится единственным реестром людей. Значит role и manager_id переезжают сюда — это отменяет решение 001:15-19 («ролей здесь нет — сознательно»), что зафиксировано в шапке файла и переписанным COMMENT ON TABLE, а не оставлено расходиться молча. Развилка Б закрыта в пользу трёх состояний: is_active заменён на access_state (active / trial_expired / disabled). Булев флаг схлопывал «пускаем, но объясняем» и «не пускаем вовсе» в одно значение — trial-экран исчезал бы без падения тестов. Семантика зафиксирована в COMMENT: trial_expired при ВЕРНОМ пароле даёт 403 с отдельным кодом и НЕ выдаёт сессию, disabled — generic 401; неверный пароль в любом состоянии остаётся generic 401, то есть защита от перечисления логинов сохраняется. user2 («Брусника») → trial_expired. Колонки role/manager_id зеркалят м.192 побуквенно (CHECK ролей, иерархический CHECK, partial index, self-FK ON DELETE SET NULL), чтобы код «Меры» переехал на auth.users без правок. Добавлен users_manager_not_self_ck — на уровне БД самоназначение менеджером иначе проходит, а второй потребитель (Птица) валидации «Меры» не имеет. Гранты. INSERT выдан — без него переезд не состоится (создание сотрудника из «Команды»). DELETE НЕ выдан: потребителя нет (в team.py только POST и PATCH), а 002:22-33 отклоняла ровно такие гранты-на-будущее; появится хендлер — появится строка GRANT в той же миграции. Табличный UPDATE из 002:80 сужен до column-level: иначе auth_app молча получил бы право писать role и access_state, и ошибка в PATCH-эндпоинте превращалась бы в тихое повышение до админа или тихое снятие блокировки. role и manager_id в список не включены — их сегодня не пишет никто. Гранта на users_id_seq нет намеренно: для GENERATED ALWAYS AS IDENTITY PostgreSQL использует NextValueExpr → nextval_internal(check_permissions := false), ACL последовательности не проверяется. Утверждение 002:26-27 («идентичность требует nextval») фактически неверно; проверено обратным экспериментом — REVOKE, затем INSERT. Проверено исполнением на postgres:16, не по комментариям: - чистая сборка 001→002→003→004 — 13 строк, роли admin/manager×2/employee×10, user2 = trial_expired, is_active отсутствует, все 6 констрейнтов на месте; - повторный прогон 004 ×2 идемпотентен; - ручные прод-правки (user2 → active, user3 → manager) переживают повтор — backfill не затирает решения владельца; - периметр auth_app: INSERT users ✓, UPDATE access_state ✓, INSERT sessions ✓; UPDATE role ✗, UPDATE manager_id ✗, DELETE ✗, CREATE TABLE ✗; - CHECK'и ловят: admin с manager_id, self-manager, access_state вне списка, role вне списка, INSERT без role. Тест: 6 passed. Добавлена проверка запрета CREATE INDEX CONCURRENTLY — в связке с обязательной обёрткой BEGIN/COMMIT это комбинация, невыполнимая на проде (25001), а отдельной проверки на неё не было.	2026-08-01 00:28:37 +03:00
bot-backend	bea61f6cd9	feat(auth): отдельная БД auth — фундамент единого входа «Меры» и «Птицы» ... PR-1 эпика: вся авторизация переезжает на одну нейтральную форму входа, браузерный popup (Caddy basic_auth) убирается. Этот PR — ТОЛЬКО фундамент, прод работает как сейчас: в БД gendesign ничего не меняется, новая БД создаётся и наполняется логинами без паролей, читать её пока некому. Почему отдельная БД, а не таблица в существующей: хранилище доступов не должно принадлежать продукту, из которого аккаунты выносятся. Сервер — существующий gendesign-postgres (новый контейнер не заводим); проверено, что оба бэкенда сидят в сети gendesign_shared и TCP-достают до него. Состав: - data/sql/auth/001-003 — схема (users, sessions), роль приложения, сид 13 логинов. password_hash = NULL у ВСЕХ: plaintext и bcrypt-хеши в git запрещены, пароли проставляются отдельно на проде (конвенция репы, прецедент tradein м.193). - ops/db-bootstrap/create_auth_db.sql — CREATE DATABASE через \gexec. Не миграцией: CREATE DATABASE запрещён в транзакции, а миграции обязаны быть транзакционными. - ops/db-bootstrap/set_auth_app_password.sql — пароль роли из env, зеркало set_tradein_fdw_password.sql (GUC + \o /dev/null + %L, строго через stdin — :'pw' не интерполируется внутри $$...$$, на этом падал деплой 2026-05-24). Схема лежит в ПОДКАТАЛОГЕ data/sql/auth/ намеренно: основной цикл деплоя использует `ls -1 data/sql/*.sql`, который в подкаталоги не рекурсирует → эти файлы физически не могут примениться в БД gendesign. Защита не на дисциплине, а на глобе. Триггер `data/sql/**` подкаталог при этом покрывает. Права: владелец БД — суперюзер, а не auth_app (иначе гранты были бы декорацией). users — только SELECT+UPDATE (INSERT не выдан: создания аккаунтов в этом PR нет, а снять грант, на который уже опирается прод-код, сложнее чем выдать). REVOKE ALL ON DATABASE FROM PUBLIC продублирован в bootstrap и в миграции намеренно: bootstrap гоняется каждый деплой (переприменяемость), миграция — однократно (самодостаточность). Проверено ИСПОЛНЕНИЕМ на postgis/postgis:16-3.4 (тот же образ, что на проде): двойной прогон всех файлов идемпотентен; COALESCE-защита сида не затирает вручную проставленные пароль/имя (проверено живьём); ASCII-CHECK отклоняет кириллицу; auth_app коннектится, посторонняя роль → permission denied; битая миграция даёт exit 1 и НЕ пишется в _schema_migrations, т.е. деплой прервётся до подъёма кода; пароль с кавычками и бэкслешем не ломает %L и не печатается в stdout. Тест backend/tests/sql/test_auth_sql_migrations.py: имена, транзакционность, наличие wiring в deploy.yml и детектор паролей/хешей, покрывающий И data/sql/auth, И ops/db-bootstrap — единственное место в репе с ALTER ROLE ... PASSWORD. Детектор проверен на живучесть: подложенный bcrypt-хеш роняет тест. Открытые развилки зафиксированы комментариями в коде, решаются в PR-2/3: судьба tradein_users/tradein_sessions (два одинаковых по схеме хранилища) и expired != disabled (trial-экран не выражается булевым is_active). NB: переменную AUTH_DB_PASSWORD нужно завести вручную в runtime-env бэкенда на VPS. Пока пусто — шаг ALTER ROLE пропускается с warning'ом, деплой не падает.	2026-07-31 21:47:33 +03:00
Light1YT	658d724075	feat(analytics): velocity-anomaly alerts (#17) + ARN ДДУ price indicator (#99) ... #17: detect_velocity_anomalies + GET /analytics/velocity-alerts — z-score drop-detection на domrf_kn_sale_graph (double-gate z≤-2 AND drop≤-30%, starvation-guards). Snapshot=richest (не MAX — prod новейшие частичные), lookback anchored на latest report_month (scrape лаг ~4мес). Prod: ЖК Центральный Парк -69%, ~14ms. #99: mv_ddu_price_indicator (миграция 152) + POST /market/ddu-indicator — ARN-mirror ценовой индекс per quarter×area_bucket из rosreestr_deals (ДДУ регион 66). MVP: subject-level, period Q, window 2025-Q2+, methods 1/2 (basis/previous, prev_period_value honesty). Q1-2026 headline 1.0185 vs ARN 1.03 (±5%). Method 3 blocked (нет pre-2025-Q2 данных) — задокументировано. Closes #17 Closes #99	2026-06-13 22:04:49 +05:00
Light1YT	e9585bcd3b	test(suite): re-align drifted tests with current code (CI-rehab 2/3) ... Suite was uncollectable for a while → code evolved, mocks didn't (42 failed / 5 errors → 1687 passed / 0 failed / 0 errors). TEST-ONLY, no app code changed, no real bugs found (code-reviewed ✅ — no test weakened to fake-green). - best_layouts: sum_deals→deals_window rename; velocity-scaling direction for new SF-01 divisors (last_month=1.0/last_year=12.0) - quarter_dump_lookup: 7→10-tuple mock rows (risks/opportunity/red_lines cols); fix early-exit call-counts for the cad_zouit fallback (#232) - cadastre_bulk: add xmin/ymin/xmax/ymax to harvest-quarter db mock - nspd_client: add required QuarterDump.opportunity - TopLayoutRow: add required is_oversold - analyze_{market_price,recent_permits,inline_weights}: SQL-signature dispatch instead of fragile positional db.execute indices (SF-B5 query reorder; also fixes a double-POST geom-starvation false-negative) - custom_pois: move centroid >15km so center_bonus=0 isolates custom-POI delta - layout/report PDF: runtime WeasyPrint probe (skip macOS dev, RUN on CI) - mv_layout SQL: normalize +psycopg DSN + connectivity-probe skipif - admin token tests: skip (X-Admin-Token gate removed #437/#426; protection is Caddy basic_auth + RBAC, covered by test_rbac) Refs #944.	2026-06-03 19:05:43 +05:00
Light1YT	07106d744a	chore(mv): regression test + sql rule for weighted AVG (#295) (#626)	2026-05-28 13:49:54 +00:00