(high) VelocityBlock.tsx/VelocityBlock: рассинхрон bucket-ключей — 4-комн. и 5+ сделки молча выпадают из «По комнатности» и «Топ продавцов» #1456

New issue

Closed

opened 2026-06-15 05:55:55 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-06-15 05:55:55 +00:00

Collaborator

Severity: high · Категория: data-integrity · Файл: frontend/src/components/site-finder/VelocityBlock.tsx:6-15, 214-249, 326-332

VelocityBlock.tsx:6-15, 214-249, 326-332. BUCKET_ORDER = ["студия","1","2","3","4+"], BUCKET_LABEL имеет ключ "4+". Таблица «По комнатности» рендерит BUCKET_ORDER.map(b => velocity.by_room_bucket?.[b]) (стр. 214-216), под-разбивка в «Топ продавцов» — BUCKET_ORDER.filter(b => (c.by_room_bucket?.[b] ?? 0) > 0) (стр. 326-332). Backend (data/sql/68_schema_objective.sql:122 подтверждено: room_bucket TEXT = "студия"|"1"|"2"|"3"|"4"|"5+") и velocity.py (backend/app/services/site_finder/velocity.py:323 GROUP BY crm.room_bucket, :351 bucket = str(row["room_bucket"]) — без нормализации в "4+") эмитят сырые ключи "4" и "5+". Фронтовый ключ "4+" никогда не совпадёт с backend-ключами "4"/"5+" → сделки по 4-комн. и 5+ квартирам полностью выпадают и из таблицы units/м²/ЖК, и из строки разбивки топ-продавцов. Сумма по строкам меньше агрегата velocity, клиент видит неполную структуру спроса (как будто 4-к/5+ не продаются). Тихая потеря данных. Фикс: привести фронт к backend-ключам (BUCKET_ORDER = ["студия","1","2","3","4","5+"] + соответствующие labels), либо нормализовать на backend (свести "4" и "5+" в "4+").

Почему баг: Ключ фронта "4+" никогда не совпадёт с backend-ключами "4" и "5+". Сделки по 4-комнатным и 5+-комнатным квартирам полностью выпадают из таблицы «По комнатности» (units/м²/ЖК) и из строки разбивки в «Топ продавцов». В итоге сумма по строкам таблицы меньше агрегатного velocity, а клиент видит неполную структуру спроса (как будто 4-к и 5+ не продаются вовсе). Это тихая потеря данных в клиентском блоке.

Как чинить: Согласовать словарь: либо нормализовать backend bucket в "4+" (объединять "4" и "5+"), либо изменить frontend BUCKET_ORDER/BUCKET_LABEL на ["студия","1","2","3","4","5+"]. Дополнительно — рендерить «прочие» ключи, которых нет в BUCKET_ORDER, чтобы ничего не терялось молча.

_{deep-audit «армия ботов 2» · verify+harden, confidence 0.92 · unit U94}

**Severity:** high · **Категория:** data-integrity · **Файл:** `frontend/src/components/site-finder/VelocityBlock.tsx:6-15, 214-249, 326-332` VelocityBlock.tsx:6-15, 214-249, 326-332. BUCKET_ORDER = ["студия","1","2","3","4+"], BUCKET_LABEL имеет ключ "4+". Таблица «По комнатности» рендерит `BUCKET_ORDER.map(b => velocity.by_room_bucket?.[b])` (стр. 214-216), под-разбивка в «Топ продавцов» — `BUCKET_ORDER.filter(b => (c.by_room_bucket?.[b] ?? 0) > 0)` (стр. 326-332). Backend (data/sql/68_schema_objective.sql:122 подтверждено: room_bucket TEXT = "студия"|"1"|"2"|"3"|"4"|"5+") и velocity.py (backend/app/services/site_finder/velocity.py:323 GROUP BY crm.room_bucket, :351 `bucket = str(row["room_bucket"])` — без нормализации в "4+") эмитят сырые ключи "4" и "5+". Фронтовый ключ "4+" никогда не совпадёт с backend-ключами "4"/"5+" → сделки по 4-комн. и 5+ квартирам полностью выпадают и из таблицы units/м²/ЖК, и из строки разбивки топ-продавцов. Сумма по строкам меньше агрегата velocity, клиент видит неполную структуру спроса (как будто 4-к/5+ не продаются). Тихая потеря данных. Фикс: привести фронт к backend-ключам (BUCKET_ORDER = ["студия","1","2","3","4","5+"] + соответствующие labels), либо нормализовать на backend (свести "4" и "5+" в "4+"). **Почему баг:** Ключ фронта `"4+"` никогда не совпадёт с backend-ключами `"4"` и `"5+"`. Сделки по 4-комнатным и 5+-комнатным квартирам полностью выпадают из таблицы «По комнатности» (units/м²/ЖК) и из строки разбивки в «Топ продавцов». В итоге сумма по строкам таблицы меньше агрегатного velocity, а клиент видит неполную структуру спроса (как будто 4-к и 5+ не продаются вовсе). Это тихая потеря данных в клиентском блоке. **Как чинить:** Согласовать словарь: либо нормализовать backend bucket в "4+" (объединять "4" и "5+"), либо изменить frontend BUCKET_ORDER/BUCKET_LABEL на ["студия","1","2","3","4","5+"]. Дополнительно — рендерить «прочие» ключи, которых нет в BUCKET_ORDER, чтобы ничего не терялось молча. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.92 · unit U94</sub>

bot-backend added the

week ревью 1

label 2026-06-15 05:55:55 +00:00

bot-backend added the

scope/frontend

label 2026-06-15 11:02:07 +00:00

lekss361 commented

2026-06-15 11:13:31 +00:00

Owner

🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)

Текущее состояние кода: frontend/src/components/site-finder/VelocityBlock.tsx:6 — BUCKET_ORDER = ["студия","1","2","3","4+"], BUCKET_LABEL (:9-15) с ключом "4+". Таблица «По комнатности» — BUCKET_ORDER.map((b) => velocity.by_room_bucket?.[b]) (:214-216). Под-разбивка «Топ продавцов» — BUCKET_ORDER.filter((b) => (c.by_room_bucket?.[b] ?? 0) > 0) (:326-332). Backend: data/sql/68_schema_objective.sql:122 — room_bucket TEXT = "студия"|"1"|"2"|"3"|"4"|"5+"; velocity.py:351 — bucket = str(row["room_bucket"]) без нормализации (raw из GROUP BY crm.room_bucket, :323/331).

Корень: фронтовый ключ "4+" никогда не совпадает с backend-ключами "4" и "5+" → сделки 4-комн. и 5+ полностью выпадают и из таблицы units/м²/ЖК, и из строки разбивки топ-продавцов. Сумма по строкам < агрегата velocity — клиент видит неполную структуру спроса (как будто 4-к/5+ не продаются). Тихая потеря данных.

Что править:

Привести фронт к backend-ключам: BUCKET_ORDER = ["студия","1","2","3","4","5+"] + соответствующие BUCKET_LABEL ("4": "4-к", "5+": "5+"). Это меняет только литерал-словарь, типы KnownBucket подстроятся автоматически.
Дополнительно (harden): рендерить «прочие» ключи by_room_bucket, которых нет в BUCKET_ORDER, чтобы ничего не терялось молча при будущем расширении на backend.
Альтернатива (если хотят объединять 4 и 5+ в одну строку UI): нормализовать на backend в velocity.py:351 — свести "4" и "5+" в "4+"; но это согласовать с тем, что schema хранит раздельно.

Что посмотреть:

Код: VelocityBlock.tsx (BUCKET_ORDER/BUCKET_LABEL, :214-249, :326-332); velocity.py:315-373 (источник ключей); src/types/site-finder.ts тип Velocity.by_room_bucket. Тест/проверка: ЖК с 4-к и 5+ сделками → сумма строк таблицы == агрегату.
Vault: code/modules/Module_Velocity_Service.md (раздел «Per-room breakdown 2026-05-15» документирует ключи 'студия','1','2',... от backend).

**🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)** **Текущее состояние кода:** `frontend/src/components/site-finder/VelocityBlock.tsx:6` — `BUCKET_ORDER = ["студия","1","2","3","4+"]`, `BUCKET_LABEL` (`:9-15`) с ключом `"4+"`. Таблица «По комнатности» — `BUCKET_ORDER.map((b) => velocity.by_room_bucket?.[b])` (`:214-216`). Под-разбивка «Топ продавцов» — `BUCKET_ORDER.filter((b) => (c.by_room_bucket?.[b] ?? 0) > 0)` (`:326-332`). Backend: `data/sql/68_schema_objective.sql:122` — `room_bucket TEXT` = `"студия"|"1"|"2"|"3"|"4"|"5+"`; `velocity.py:351` — `bucket = str(row["room_bucket"])` без нормализации (raw из `GROUP BY crm.room_bucket`, `:323/331`). **Корень:** фронтовый ключ `"4+"` никогда не совпадает с backend-ключами `"4"` и `"5+"` → сделки 4-комн. и 5+ полностью выпадают и из таблицы units/м²/ЖК, и из строки разбивки топ-продавцов. Сумма по строкам < агрегата velocity — клиент видит неполную структуру спроса (как будто 4-к/5+ не продаются). Тихая потеря данных. **Что править:** - Привести фронт к backend-ключам: `BUCKET_ORDER = ["студия","1","2","3","4","5+"]` + соответствующие `BUCKET_LABEL` (`"4": "4-к"`, `"5+": "5+"`). Это меняет только литерал-словарь, типы `KnownBucket` подстроятся автоматически. - Дополнительно (harden): рендерить «прочие» ключи `by_room_bucket`, которых нет в `BUCKET_ORDER`, чтобы ничего не терялось молча при будущем расширении на backend. - Альтернатива (если хотят объединять 4 и 5+ в одну строку UI): нормализовать на backend в `velocity.py:351` — свести `"4"` и `"5+"` в `"4+"`; но это согласовать с тем, что schema хранит раздельно. **Что посмотреть:** - Код: `VelocityBlock.tsx` (`BUCKET_ORDER`/`BUCKET_LABEL`, `:214-249`, `:326-332`); `velocity.py:315-373` (источник ключей); `src/types/site-finder.ts` тип `Velocity.by_room_bucket`. Тест/проверка: ЖК с 4-к и 5+ сделками → сумма строк таблицы == агрегату. - Vault: `code/modules/Module_Velocity_Service.md` (раздел «Per-room breakdown 2026-05-15» документирует ключи `'студия','1','2',...` от backend).