fix(sf-04): seed PRINZIP project mappings в objective_complex_mapping (Малевич + Ньютон парк) #273

Merged

lekss361 merged 1 commit from fix/sf-04-malevich-mapping into main

2026-05-17 09:04:18 +00:00

lekss361 commented

2026-05-17 09:00:52 +00:00

Owner

Summary

SF FixList #4 — partial scope (Малевич + Ньютон парк).

objective_corpus_room_month содержит активные сделки для Малевич (98/12m) и Ньютон парк (30/12m), но записей в objective_complex_mapping не было → mv_layout_velocity пропускал оба проекта в velocity calculations.

Изменения

data/sql/103_seed_prinzip_mappings.sql:

Малевич → domrf_obj_id 64701 (Строящиеся, 244 кв, сдача 2027-09)
Ньютон парк → domrf_obj_id 47390 (Сданные, 411 кв, крупнейший corpus)

Idempotent: ON CONFLICT DO NOTHING.

Post-merge step

После merge — manual REFRESH MV (тяжёлая операция, не в migration):

docker compose -p gendesign exec postgres \
  psql -U gendesign -d gendesign -c \
  "REFRESH MATERIALIZED VIEW CONCURRENTLY mv_layout_velocity;"

Scope note (user request)

⚠️ Этот PR — только 2 явно обнаруженных проектa (PRINZIP focus). User расширил scope: audit ВСЕХ ЖК с активностью в Objective но без mapping. Будет отдельный follow-up sub-PR (item #4b в epic #271).

Related: epic #271 item #4 (Wave 1, partial)

## Summary SF FixList #4 — partial scope (Малевич + Ньютон парк). `objective_corpus_room_month` содержит активные сделки для Малевич (98/12m) и Ньютон парк (30/12m), но записей в `objective_complex_mapping` не было → `mv_layout_velocity` пропускал оба проекта в velocity calculations. ## Изменения `data/sql/103_seed_prinzip_mappings.sql`: - Малевич → domrf_obj_id `64701` (Строящиеся, 244 кв, сдача 2027-09) - Ньютон парк → domrf_obj_id `47390` (Сданные, 411 кв, крупнейший corpus) Idempotent: `ON CONFLICT DO NOTHING`. ## Post-merge step После merge — **manual REFRESH MV** (тяжёлая операция, не в migration): ```bash docker compose -p gendesign exec postgres \ psql -U gendesign -d gendesign -c \ "REFRESH MATERIALIZED VIEW CONCURRENTLY mv_layout_velocity;" ``` ## Scope note (user request) ⚠️ Этот PR — **только** 2 явно обнаруженных проектa (PRINZIP focus). User расширил scope: **audit ВСЕХ ЖК** с активностью в Objective но без mapping. Будет отдельный follow-up sub-PR (item #4b в epic #271). Related: epic #271 item #4 (Wave 1, partial)

lekss361 added 1 commit 2026-05-17 09:00:53 +00:00

fix(sf-04): seed PRINZIP project mappings в objective_complex_mapping 31b13c18b1

Audit 2026-05-17: objective_corpus_room_month содержал активные сделки
для Малевич (98/12m) и Ньютон парк (30/12m), но записей в
objective_complex_mapping не было → mv_layout_velocity пропускал оба
проекта в velocity calculations.

Добавлены маппинги:
- Малевич → domrf_obj_id 64701 (Строящиеся, 244кв, сдача 2027-09)
- Ньютон парк → domrf_obj_id 47390 (Сданные, 411кв, крупнейший corpus)

ON CONFLICT DO NOTHING — идемпотентно. REFRESH mv_layout_velocity
выполняется вручную post-deploy (runbooks/Refresh_MV_Layout_Velocity.md).

Closes (epic part) #271 item 4

lekss361 commented

2026-05-17 09:04:09 +00:00

Author

Owner

Deep review — APPROVE

Verdict: APPROVE (merging).

Корректность

Migration naming 103_ — sequential после 102_cad_nspd_overlay_tables.sql, correct.
BEGIN/COMMIT wrap — есть.
ON CONFLICT (objective_complex_name, objective_group) DO NOTHING — точное совпадение с реальным UNIQUE constraint (objective_complex_mapping_objective_complex_name_objective__key). Idempotent.
INSERT shape: (objective_complex_name, objective_group, domrf_obj_id, match_method, is_reviewed, note) — все NOT NULL поля покрыты (is_reviewed=true, остальные дефолтные created_at/updated_at = now()).
FK на domrf_obj_id → domrf_kn_objects.obj_id отсутствует (FK не объявлен в 68_schema_objective.sql), так что INSERT не упадёт. Однако obj_id 64701 / 47390 верифицированы — оба существуют в domrf_kn_objects.
Existing mapping conflict check: только 1 строка matches PRINZIP-related (видимо Парк Победы obj_id=60160) — не пересекается с Малевич/Ньютон парк.

Cross-impact

mv_layout_velocity (94_mv_layout_velocity.sql:65-66) — INNER JOIN на objective_complex_name = project_name → после REFRESH оба проекта появятся в velocity.
backend/app/services/site_finder/velocity.py:178,224 — читает objective_complex_mapping, INNER JOIN тоже подхватит. Существующие mappings (114 rows) не задеты — pure INSERT.
73_complexes_master.sql:182 — backfill complex_sources из mapping. Уже применённая миграция, на новых rows не влияет (миграция выполняется один раз).

Conventions

sql.md compliant: BEGIN/COMMIT, ON CONFLICT DO NOTHING, header с контекстом, dependencies, deploy notes.
_schema_migrations auto-tracking через .forgejo/workflows/deploy.yml:223 — корректно сработает.

Vault

fixes/Fix_SF_Malevich_Mapping_May17.md — присутствует.
runbooks/Refresh_MV_Layout_Velocity.md — присутствует, ссылается на эту migration.
code/modules/Module_Velocity_Service.md — задокументировано.

После merge

Manual step — REFRESH MV CONCURRENTLY (не происходит автоматически):

docker compose -p gendesign exec postgres \
  psql -U gendesign -d gendesign -c \
  "REFRESH MATERIALIZED VIEW CONCURRENTLY mv_layout_velocity;"

Без REFRESH MV новые mappings не отразятся в velocity. Runbook: runbooks/Refresh_MV_Layout_Velocity.md.

Risk: Low. Reversibility: easy (DELETE FROM objective_complex_mapping WHERE domrf_obj_id IN (64701, 47390) AND match_method='manual').

## Deep review — APPROVE **Verdict:** APPROVE (merging). ### Корректность - Migration naming `103_` — sequential после `102_cad_nspd_overlay_tables.sql`, correct. - `BEGIN/COMMIT` wrap — есть. - `ON CONFLICT (objective_complex_name, objective_group) DO NOTHING` — точное совпадение с реальным UNIQUE constraint (`objective_complex_mapping_objective_complex_name_objective__key`). Idempotent. - INSERT shape: `(objective_complex_name, objective_group, domrf_obj_id, match_method, is_reviewed, note)` — все NOT NULL поля покрыты (`is_reviewed=true`, остальные дефолтные `created_at/updated_at` = `now()`). - FK на `domrf_obj_id` → `domrf_kn_objects.obj_id` отсутствует (FK не объявлен в `68_schema_objective.sql`), так что INSERT не упадёт. Однако obj_id 64701 / 47390 верифицированы — оба существуют в `domrf_kn_objects`. - Existing mapping conflict check: только 1 строка matches PRINZIP-related (видимо Парк Победы obj_id=60160) — не пересекается с Малевич/Ньютон парк. ### Cross-impact - `mv_layout_velocity` (94_mv_layout_velocity.sql:65-66) — INNER JOIN на `objective_complex_name = project_name` → после REFRESH оба проекта появятся в velocity. - `backend/app/services/site_finder/velocity.py:178,224` — читает `objective_complex_mapping`, INNER JOIN тоже подхватит. Существующие mappings (114 rows) не задеты — pure INSERT. - `73_complexes_master.sql:182` — backfill `complex_sources` из mapping. Уже применённая миграция, на новых rows не влияет (миграция выполняется один раз). ### Conventions - sql.md compliant: `BEGIN/COMMIT`, `ON CONFLICT DO NOTHING`, header с контекстом, dependencies, deploy notes. - `_schema_migrations` auto-tracking через `.forgejo/workflows/deploy.yml:223` — корректно сработает. ### Vault - `fixes/Fix_SF_Malevich_Mapping_May17.md` — присутствует. - `runbooks/Refresh_MV_Layout_Velocity.md` — присутствует, ссылается на эту migration. - `code/modules/Module_Velocity_Service.md` — задокументировано. ### После merge Manual step — REFRESH MV CONCURRENTLY (не происходит автоматически): ```bash docker compose -p gendesign exec postgres \ psql -U gendesign -d gendesign -c \ "REFRESH MATERIALIZED VIEW CONCURRENTLY mv_layout_velocity;" ``` Без REFRESH MV новые mappings не отразятся в velocity. Runbook: `runbooks/Refresh_MV_Layout_Velocity.md`. Risk: Low. Reversibility: easy (`DELETE FROM objective_complex_mapping WHERE domrf_obj_id IN (64701, 47390) AND match_method='manual'`).