[Fable 5][P3] OCR-нормализация не чинит задокументированный шум «6б:41:…» — кад-номера тихо теряются #1228

New issue

Closed

opened 2026-06-13 04:49:46 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-13 04:49:46 +00:00

Collaborator

Из армейского ревью Claude Fable 5 (2026-06-11)

Confirmed by 2/2 адверсариальных верификатора, severity P3 (correctness), confidence 0.8.

Файл

backend/app/services/scrapers/izyatie_ocr.py:78

Evidence (цитата кода)

# б (кирилл.) → 6, если справа стоит «6:» (т.е. первые два символа кад-номера).
text = re.sub(r"\bб(?=6:)", "6", text, flags=re.IGNORECASE)

Why bug

Docstring модуля заявляет обработку шума «б» вместо «6»: «6б:41:...». Но в «6б:41» между цифрой 6 и «б» нет word boundary (оба \w) → \bб не матчится, а lookahead (?=6:) ждёт «6:», фактически дальше «:4». Проверено репро: '6б:41:0702048:26' остаётся ненормализованным → _RE_CAD_NUM (требует '66:…') не находит номер → запись об изъятии ЗУ молча выпадает (ни warning, ни записи в БД).

Suggested fix

Добавить правило для второй позиции: text = re.sub(r"(?<=6)б(?=:)", "6", text, flags=re.IGNORECASE) рядом с существующей заменой.

Verify notes

[real/P3] Репро подтвердил: в «6б:41» нет \b между «6» и «б» (оба \w), а lookahead (?=6:) ждёт «6:», но после «б» стоит «:4» — regex не матчит задокументированный (docstring стр.10) шум «6б:41:…», чинит лишь зеркальный «б6:41:…». «6б:41:0702048:26» остаётся ненормализованным, _RE_CAD_NUM (литерал «66:») его не находит → запись об изъятии тихо выпадает (макс. logger.debug). P3: потеря recall в best-effort OCR, без краша/порчи данных.
[real/P3] Защиты нет: таск передаёт OCR-текст напрямую, иной нормализации «б» нет. Репро подтверждён: '6б:41:0702048:26' не матчится \bб(?=6:) — между 6 и б нет \b (оба \w), после б стоит ':4', не '6:' → _RE_CAD_NUM не находит номер → запись молча выпадает. Регекс чинит лишь «б6:», но docstring (стр.10) и inline-комментарий (стр.76) заявляют именно «6б:41»→«66:41»; тест покрывает только б6:. P3: потеря recall в best-effort OCR, не порча данных.

Provenance

Finders: scrapers
Confidence: 0.8
Originally batched at: main@d796027

## Из армейского ревью Claude Fable 5 (2026-06-11) Confirmed by 2/2 адверсариальных верификатора, severity **P3** (correctness), confidence 0.8. ## Файл [`backend/app/services/scrapers/izyatie_ocr.py:78`](backend/app/services/scrapers/izyatie_ocr.py:78) ## Evidence (цитата кода) ``` # б (кирилл.) → 6, если справа стоит «6:» (т.е. первые два символа кад-номера). text = re.sub(r"\bб(?=6:)", "6", text, flags=re.IGNORECASE) ``` ## Why bug Docstring модуля заявляет обработку шума «б» вместо «6»: «6б:41:...». Но в «6б:41» между цифрой 6 и «б» нет word boundary (оба \w) → \bб не матчится, а lookahead (?=6:) ждёт «6:», фактически дальше «:4». Проверено репро: '6б:41:0702048:26' остаётся ненормализованным → _RE_CAD_NUM (требует '66:…') не находит номер → запись об изъятии ЗУ молча выпадает (ни warning, ни записи в БД). ## Suggested fix Добавить правило для второй позиции: text = re.sub(r"(?<=6)б(?=:)", "6", text, flags=re.IGNORECASE) рядом с существующей заменой. ## Verify notes - [real/P3] Репро подтвердил: в «6б:41» нет \b между «6» и «б» (оба \w), а lookahead (?=6:) ждёт «6:», но после «б» стоит «:4» — regex не матчит задокументированный (docstring стр.10) шум «6б:41:…», чинит лишь зеркальный «б6:41:…». «6б:41:0702048:26» остаётся ненормализованным, _RE_CAD_NUM (литерал «66:») его не находит → запись об изъятии тихо выпадает (макс. logger.debug). P3: потеря recall в best-effort OCR, без краша/порчи данных. - [real/P3] Защиты нет: таск передаёт OCR-текст напрямую, иной нормализации «б» нет. Репро подтверждён: '6б:41:0702048:26' не матчится \bб(?=6:) — между 6 и б нет \b (оба \w), после б стоит ':4', не '6:' → _RE_CAD_NUM не находит номер → запись молча выпадает. Регекс чинит лишь «б6:», но docstring (стр.10) и inline-комментарий (стр.76) заявляют именно «6б:41»→«66:41»; тест покрывает только б6:. P3: потеря recall в best-effort OCR, не порча данных. ## Provenance - Finders: `scrapers` - Confidence: 0.8 - Originally batched at: main@d796027