fix(ptica): число ЗОУИТ перестаёт подписываться как число типов (#2464) #2961

Merged

bot-backend merged 1 commit from fix/2464-zouit-count-label into main

2026-08-20 09:17:07 +00:00

bot-backend commented

2026-08-20 08:53:53 +00:00

Collaborator

Пункт эпика #2464: full_report_docx.py:288. Оказалось — в обоих экспортёрах сразу.

Что не так

encumbrance.zouit_count приходит из parcels.py как len(zouit_rows) — число записей cad_zouit, пересёкших участок. Типы лежат отдельно, в zouit_types, и показаны строкой ниже.

Оба экспортёра подписывали это число как «Кол-во типов ЗОУИТ».

Насколько часто это врёт

По реальным отчётам (analysis_runs):


разборов с ЗОУИТ	1637
где записей ≠ типов	717 (43.8 %)
среднее отношение	1.35×
максимум по проду	7 записей при 3 типах

Почти в половине отчётов с ЗОУИТ читателю показывали число, которое в среднем на треть больше того, что обещает подпись.

Почему правлю подпись, а не значение

Пункт эпика предлагал обратное — заменить значение на len(zouit_types). Это сделало бы фолбэк несогласованным с основным путём: у источника счётчик считает записи, и таким же он уходит в чат-контекст (chat/retrieval.py). Значение верное — врёт подпись.

Тест

Инвариант сформулирован по смыслу, а не сверкой с выбранной мной строкой:

если подпись обещает типы, показанное число обязано равняться числу типов

Такая формулировка переживёт разумное переименование и не даст «починить» тест подгонкой подписи. Проверяются оба формата.

Против origin/main (5 записей, 2 типа):

html: подпись «Кол-во типов ЗОУИТ» показывает 5, типов 2  → падает
docx: то же самое                                        → падает
число записей всё ещё в сводке   → контроль, зелёный с обеих сторон
перечисление типов на месте      → контроль, зелёный с обеих сторон

Контроли не для симметрии: первый ловит «починку», которая выкинула бы счётчик вместо переименования, второй — потерю перечисления типов.

Прогоны

tests/services/exporters + tests/services/chat   302 passed   rc=0

Пункт эпика #2464: `full_report_docx.py:288`. Оказалось — в обоих экспортёрах сразу. ## Что не так `encumbrance.zouit_count` приходит из `parcels.py` как `len(zouit_rows)` — число **записей** `cad_zouit`, пересёкших участок. Типы лежат отдельно, в `zouit_types`, и показаны строкой ниже. Оба экспортёра подписывали это число как «Кол-во **типов** ЗОУИТ». ## Насколько часто это врёт По реальным отчётам (`analysis_runs`): | | | |---|---| | разборов с ЗОУИТ | 1637 | | где записей ≠ типов | **717 (43.8 %)** | | среднее отношение | 1.35× | | максимум по проду | 7 записей при 3 типах | Почти в половине отчётов с ЗОУИТ читателю показывали число, которое в среднем на треть больше того, что обещает подпись. ## Почему правлю подпись, а не значение Пункт эпика предлагал обратное — заменить значение на `len(zouit_types)`. Это сделало бы фолбэк несогласованным с основным путём: у источника счётчик считает записи, и таким же он уходит в чат-контекст (`chat/retrieval.py`). Значение верное — врёт подпись. ## Тест Инвариант сформулирован **по смыслу**, а не сверкой с выбранной мной строкой: > если подпись обещает типы, показанное число обязано равняться числу типов Такая формулировка переживёт разумное переименование и не даст «починить» тест подгонкой подписи. Проверяются оба формата. Против `origin/main` (5 записей, 2 типа): ``` html: подпись «Кол-во типов ЗОУИТ» показывает 5, типов 2 → падает docx: то же самое → падает число записей всё ещё в сводке → контроль, зелёный с обеих сторон перечисление типов на месте → контроль, зелёный с обеих сторон ``` Контроли не для симметрии: первый ловит «починку», которая выкинула бы счётчик вместо переименования, второй — потерю перечисления типов. ## Прогоны ``` tests/services/exporters + tests/services/chat 302 passed rc=0 ```

bot-backend added 1 commit 2026-08-20 08:53:54 +00:00

fix(ptica): число ЗОУИТ перестаёт подписываться как число типов (#2464 )

CI Trade-In / changes (pull_request) Successful in 7s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI / changes (pull_request) Successful in 8s

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 2m21s

Details

CI / backend-tests (pull_request) Successful in 17m16s

Details

be446482d0

encumbrance.zouit_count приходит из parcels.py как len(zouit_rows) — число ЗАПИСЕЙ
cad_zouit, пересёкших участок. Типы лежат отдельно, в zouit_types, и показаны
строкой ниже. Оба экспортёра подписывали это число как «Кол-во типов ЗОУИТ».

Расхождение не редкое — померил по реальным отчётам (analysis_runs):

  разборов с ЗОУИТ                1637
  где записей != типов             717   (43.8%)
  среднее отношение              1.35x
  максимум по проду        7 записей при 3 типах

То есть почти в половине отчётов с ЗОУИТ читателю показывали число, которое на
треть больше того, что обещает подпись.

Пункт эпика предлагал обратное — заменить значение на len(zouit_types). Это
сделало бы фолбэк несогласованным с основным путём: у источника счётчик считает
записи, и таким он приходит в чат-контекст (chat/retrieval.py) тоже. Врёт
подпись, её и правлю.

Тест формулирует инвариант по смыслу, а не сверкой с выбранной строкой: ЕСЛИ
подпись обещает типы, показанное число обязано равняться числу типов. Такая
формулировка переживёт разумное переименование и не даст «починить» тест
подгонкой подписи. Проверяются оба формата — HTML и DOCX.

Против origin/main (5 записей, 2 типа):

  html: подпись «Кол-во типов ЗОУИТ» показывает 5, типов 2  → падает
  docx: то же самое                                        → падает
  число записей всё ещё в сводке     — контроль, зелёный с обеих сторон
  перечисление типов на месте        — контроль, зелёный с обеих сторон

Контроли не для симметрии: первый ловит «починку», которая выкинула бы счётчик
вместо переименования, второй — потерю перечисления типов.

Прогоны: tests/services/exporters + tests/services/chat — 302 passed rc=0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>