gate_verdict: warning NO_ENGINEERING_NEARBY при ОТСУТСТВИИ инж.сетей форсирует «С ограничениями» вместо «Можно» — чистый вердикт недостижим для жилого учас… #1617

New issue

Closed

opened 2026-06-16 17:20:45 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:20:45 +00:00

Collaborator

Severity: medium · Категория: logic/verdict correctness · Файл: backend/app/services/site_finder/gate_verdict.py:252-260, 264-272

Файл: backend/app/services/site_finder/gate_verdict.py:254-260 (Check 3) и 264-272 (финальная агрегация).

Суть: Check 3 добавляет warning при ПУСТОМ engineering-списке: if not (nspd_engineering_nearby or []): warnings.append(Warning(code='NO_ENGINEERING_NEARBY', ...)). В агрегации label='Можно' выдаётся ТОЛЬКО когда blockers пуст И warnings пуст (стр. 270-272); любой непустой warnings без blockers → can_build=True, label='С ограничениями' (стр. 267-269).

Источник nspd_engineering_nearby — _get_engineering_nearby (quarter_dump_lookup.py:449-518): отдаёт [] при engineering_count==0 (ранний return, стр. 460-461), при отсутствии слоя engineering_structures в дампе квартала и при ошибке запроса (стр. 516-518) — то есть [] для значительной доли участков.

Импакт: для полностью жилого участка с определённой ПЗЗ-зоной и без ЗОУИТ-overlaps единственный возможный warning — NO_ENGINEERING_NEARBY. Если рядом нет инж.сооружений в дампе, user-facing банер gate_verdict (G5 «Можно ли тут МКД?», parcels.py:2830) никогда не покажет «Можно», всегда «С ограничениями». Семантика инвертирована: отсутствие сетей рядом — это вопрос стоимости подключения, а не градостроительное ограничение; не должно понижать чистый вердикт. Постоянная ложно-пессимистичная метка путает девелопера.

Фикс: не понижать verdict_label из-за NO_ENGINEERING_NEARBY — либо вынести его в отдельное информационное поле (info/notes), не входящее в агрегацию label, либо завести отдельную категорию infos, и при пустых blockers+warnings (но непустых infos) оставлять label='Можно'. Комментарий Check 3 уже отмечает «warning only, not a blocker» — но текущая агрегация всё равно превращает его в ограничение.

Почему баг: Семантика инвертирована/искажена: ОТСУТСТВИЕ инженерных сетей рядом помечается как «ограничение» застройки, тогда как для строительства МКД отсутствие сетей — это вопрос подключения/затрат, а не градостроительное ограничение, и уж точно не должно блокировать достижение чистого вердикта «Можно». В результате user-facing банер gate_verdict (G5, «Можно ли тут МКД?») фактически не может показать «Можно» даже для полностью жилой зоны без ЗОУИТ-блокеров — постоянная ложно-пессимистичная метка, путающая девелопера. Это отдельный код-путь от #1353 (тот про детект жилой зоны).

Как чинить: Либо вообще не порождать warning из отсутствия сетей (тогда чистый участок даёт «Можно»), либо вынести NO_ENGINEERING_NEARBY в отдельное информационное поле (info/notes), не влияющее на verdict_label; в крайнем случае не учитывать этот конкретный warning при выборе между 'Можно' и 'С ограничениями'.

_{deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.82 · unit B39}

**Severity:** medium · **Категория:** logic/verdict correctness · **Файл:** `backend/app/services/site_finder/gate_verdict.py:252-260, 264-272` Файл: backend/app/services/site_finder/gate_verdict.py:254-260 (Check 3) и 264-272 (финальная агрегация). Суть: Check 3 добавляет warning при ПУСТОМ engineering-списке: `if not (nspd_engineering_nearby or []): warnings.append(Warning(code='NO_ENGINEERING_NEARBY', ...))`. В агрегации label='Можно' выдаётся ТОЛЬКО когда blockers пуст И warnings пуст (стр. 270-272); любой непустой warnings без blockers → can_build=True, label='С ограничениями' (стр. 267-269). Источник nspd_engineering_nearby — _get_engineering_nearby (quarter_dump_lookup.py:449-518): отдаёт [] при engineering_count==0 (ранний return, стр. 460-461), при отсутствии слоя engineering_structures в дампе квартала и при ошибке запроса (стр. 516-518) — то есть [] для значительной доли участков. Импакт: для полностью жилого участка с определённой ПЗЗ-зоной и без ЗОУИТ-overlaps единственный возможный warning — NO_ENGINEERING_NEARBY. Если рядом нет инж.сооружений в дампе, user-facing банер gate_verdict (G5 «Можно ли тут МКД?», parcels.py:2830) никогда не покажет «Можно», всегда «С ограничениями». Семантика инвертирована: отсутствие сетей рядом — это вопрос стоимости подключения, а не градостроительное ограничение; не должно понижать чистый вердикт. Постоянная ложно-пессимистичная метка путает девелопера. Фикс: не понижать verdict_label из-за NO_ENGINEERING_NEARBY — либо вынести его в отдельное информационное поле (info/notes), не входящее в агрегацию label, либо завести отдельную категорию `infos`, и при пустых blockers+warnings (но непустых infos) оставлять label='Можно'. Комментарий Check 3 уже отмечает «warning only, not a blocker» — но текущая агрегация всё равно превращает его в ограничение. **Почему баг:** Семантика инвертирована/искажена: ОТСУТСТВИЕ инженерных сетей рядом помечается как «ограничение» застройки, тогда как для строительства МКД отсутствие сетей — это вопрос подключения/затрат, а не градостроительное ограничение, и уж точно не должно блокировать достижение чистого вердикта «Можно». В результате user-facing банер gate_verdict (G5, «Можно ли тут МКД?») фактически не может показать «Можно» даже для полностью жилой зоны без ЗОУИТ-блокеров — постоянная ложно-пессимистичная метка, путающая девелопера. Это отдельный код-путь от #1353 (тот про детект жилой зоны). **Как чинить:** Либо вообще не порождать warning из отсутствия сетей (тогда чистый участок даёт «Можно»), либо вынести NO_ENGINEERING_NEARBY в отдельное информационное поле (info/notes), не влияющее на verdict_label; в крайнем случае не учитывать этот конкретный warning при выборе между 'Можно' и 'С ограничениями'. --- <sub>deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.82 · unit B39</sub>