(medium) Section1ParcelInfo POI-fallback: инвест-балл участка показывается как POI-score «X / 100» с фейковыми weight/score_contribution #1466

New issue

Closed

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

bot-backend commented

2026-06-15 05:56:47 +00:00

Collaborator

Severity: medium · Категория: report · Файл: frontend/src/components/site-finder/analysis/Section1ParcelInfo.tsx:296-316

Section1ParcelInfo.tsx:296-316. Когда useParcelPoiScoreQuery (B6) ещё грузится или упал (retry:1 → error → poiQuery.data === undefined), берётся fallback-ветка (строки 301-316): PoiList2Gis получает totalScore={data.score}. data.score — это общий инвест-балл участка (шкала 0-100, те же пороги 80/65/45, что в scoreColor:206-213 и scoreVerdict:49-65), а PoiList2Gis.tsx:133 рендерит totalScore как «{totalScore.toFixed(0)} / 100» под шапкой «POI · 2ГИС / OSM» — то есть подписывает инвест-балл как POI-оценку. Дополнительно каждому элементу проставляются захардкоженные weight:0.1 и score_contribution:5 (строки 310-311): PoiList2Gis.tsx:214 показывает их как бейдж «×0.10» у всех POI, а сортировка PoiList2Gis.tsx:75 по score_contribution становится бессмысленной (все 5). В нормальной ветке (строка 299) totalScore=poiData.poi_weighted_score — семантически другое значение, что подтверждает рассинхрон. Импакт: в реально достижимом fallback (первичная загрузка B6 + любой сбой эндпоинта poi-score) клиент видит число «общий скоринг участка» под подписью «взвешенный POI-score /100» плюс одинаковые выдуманные веса. Как чинить: в fallback не подставлять data.score под POI-метку — либо скрывать строку «X / 100» при отсутствии poiData, либо считать корректный взвешенный POI-score из score_breakdown, и не хардкодить weight/score_contribution (или прятать бейджи/не сортировать, когда веса синтетические).

Почему баг: В fallback (а он реально достижим: первичная загрузка + любой сбой эндпоинта poi-score) клиент видит число, означающее одно (общий скоринг участка), под подписью, означающей другое (взвешенный POI-score «/100»), плюс одинаковые выдуманные веса ×0.10 у всех POI. Это рассинхрон данных и подписи в клиентской секции 1. В обычной ветке (poiData != null) totalScore = poiData.poi_weighted_score, что подтверждает, что эти два значения семантически разные.

Как чинить: В fallback не показывать «/100»-скор и не выдумывать веса: либо не рендерить блок POI пока poiData нет (показать состояние загрузки/ «нет данных»), либо передавать осмысленный POI-агрегат, а не data.score; убрать захардкоженные weight:0.1 / score_contribution:5.

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

**Severity:** medium · **Категория:** report · **Файл:** `frontend/src/components/site-finder/analysis/Section1ParcelInfo.tsx:296-316` Section1ParcelInfo.tsx:296-316. Когда useParcelPoiScoreQuery (B6) ещё грузится или упал (retry:1 → error → poiQuery.data === undefined), берётся fallback-ветка (строки 301-316): PoiList2Gis получает totalScore={data.score}. data.score — это общий инвест-балл участка (шкала 0-100, те же пороги 80/65/45, что в scoreColor:206-213 и scoreVerdict:49-65), а PoiList2Gis.tsx:133 рендерит totalScore как «{totalScore.toFixed(0)} / 100» под шапкой «POI · 2ГИС / OSM» — то есть подписывает инвест-балл как POI-оценку. Дополнительно каждому элементу проставляются захардкоженные weight:0.1 и score_contribution:5 (строки 310-311): PoiList2Gis.tsx:214 показывает их как бейдж «×0.10» у всех POI, а сортировка PoiList2Gis.tsx:75 по score_contribution становится бессмысленной (все 5). В нормальной ветке (строка 299) totalScore=poiData.poi_weighted_score — семантически другое значение, что подтверждает рассинхрон. Импакт: в реально достижимом fallback (первичная загрузка B6 + любой сбой эндпоинта poi-score) клиент видит число «общий скоринг участка» под подписью «взвешенный POI-score /100» плюс одинаковые выдуманные веса. Как чинить: в fallback не подставлять data.score под POI-метку — либо скрывать строку «X / 100» при отсутствии poiData, либо считать корректный взвешенный POI-score из score_breakdown, и не хардкодить weight/score_contribution (или прятать бейджи/не сортировать, когда веса синтетические). **Почему баг:** В fallback (а он реально достижим: первичная загрузка + любой сбой эндпоинта poi-score) клиент видит число, означающее одно (общий скоринг участка), под подписью, означающей другое (взвешенный POI-score «/100»), плюс одинаковые выдуманные веса ×0.10 у всех POI. Это рассинхрон данных и подписи в клиентской секции 1. В обычной ветке (poiData != null) totalScore = poiData.poi_weighted_score, что подтверждает, что эти два значения семантически разные. **Как чинить:** В fallback не показывать «/100»-скор и не выдумывать веса: либо не рендерить блок POI пока poiData нет (показать состояние загрузки/ «нет данных»), либо передавать осмысленный POI-агрегат, а не data.score; убрать захардкоженные weight:0.1 / score_contribution:5. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.85 · unit U99</sub>

bot-backend added the

week ревью 1

label 2026-06-15 05:56:47 +00:00

bot-backend added the

scope/backend

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

lekss361 referenced this issue

2026-06-15 11:25:32 +00:00

(medium) PoiList2Gis/site-finder-api: «{totalScore}/100» может превышать 100 и в fallback показывает не POI-метрику #1470

lekss361 commented

2026-06-15 11:25:56 +00:00

Owner

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

Текущее состояние кода: frontend/src/components/site-finder/analysis/Section1ParcelInfo.tsx:166 (poiQuery = useParcelPoiScoreQuery(cad)), :185 (poiData = poiQuery.data), нормальная ветка :280-284 (totalScore={poiData.poi_weighted_score}), fallback :285-299. Рендер метки — PoiList2Gis.tsx:123 («POI · 2ГИС / OSM»), :133 ({totalScore.toFixed(0)} / 100).

Корень: Fallback достижим, когда poiData === undefined (первичная загрузка B6 или ошибка эндпоинта). В нём totalScore={data.score} (стр.298) — это общий инвест-балл участка 0..100 (те же пороги, что scoreColor/scoreVerdict), отрисованный под POI-подписью «/ 100». Дополнительно каждому POI хардкодятся weight: 0.1 и score_contribution: 5 (стр.294-295) → PoiList2Gis показывает бейдж «×0.10» у всех и сортировка по score_contribution теряет смысл (все 5). В нормальной ветке totalScore = poiData.poi_weighted_score (стр.283) — семантически другое значение, что подтверждает рассинхрон.

Что править:

В fallback не подставлять data.score под POI-метку: либо не рендерить блок POI пока poiData нет (показать загрузку/«нет данных»), либо передавать осмысленный POI-агрегат.
Убрать захардкоженные weight: 0.1 / score_contribution: 5 (стр.294-295) — либо скрывать бейджи и не сортировать когда веса синтетические.
Пересекается с #1470 (адаптер site-finder-api.ts:533-543 сам ненормирован) — согласовать.

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

Код: Section1ParcelInfo.tsx:166, :185, :280-299; PoiList2Gis.tsx:75 (сортировка по score_contribution), :123-133, :214 (бейдж weight).
Vault: релевантных заметок не найдено.

**🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)** **Текущее состояние кода:** `frontend/src/components/site-finder/analysis/Section1ParcelInfo.tsx:166` (`poiQuery = useParcelPoiScoreQuery(cad)`), `:185` (`poiData = poiQuery.data`), нормальная ветка `:280-284` (`totalScore={poiData.poi_weighted_score}`), fallback `:285-299`. Рендер метки — `PoiList2Gis.tsx:123` («POI · 2ГИС / OSM»), `:133` (`{totalScore.toFixed(0)} / 100`). **Корень:** Fallback достижим, когда `poiData === undefined` (первичная загрузка B6 или ошибка эндпоинта). В нём `totalScore={data.score}` (стр.298) — это общий инвест-балл участка 0..100 (те же пороги, что `scoreColor`/`scoreVerdict`), отрисованный под POI-подписью «/ 100». Дополнительно каждому POI хардкодятся `weight: 0.1` и `score_contribution: 5` (стр.294-295) → `PoiList2Gis` показывает бейдж «×0.10» у всех и сортировка по `score_contribution` теряет смысл (все 5). В нормальной ветке `totalScore = poiData.poi_weighted_score` (стр.283) — семантически другое значение, что подтверждает рассинхрон. **Что править:** - В fallback не подставлять `data.score` под POI-метку: либо не рендерить блок POI пока `poiData` нет (показать загрузку/«нет данных»), либо передавать осмысленный POI-агрегат. - Убрать захардкоженные `weight: 0.1` / `score_contribution: 5` (стр.294-295) — либо скрывать бейджи и не сортировать когда веса синтетические. - Пересекается с #1470 (адаптер `site-finder-api.ts:533-543` сам ненормирован) — согласовать. **Что посмотреть:** - Код: `Section1ParcelInfo.tsx:166`, `:185`, `:280-299`; `PoiList2Gis.tsx:75` (сортировка по score_contribution), `:123-133`, `:214` (бейдж weight). - Vault: релевантных заметок не найдено.