contracts-flask/History/opus-dedup-2026-06-28.md

Запрос Opus — логика дедупликации в пайплайне

Дата: 28.06.2026

Проблема

Сейчас:

1. Загрузка: дубликат файла определяется только по имени (filename). Тот же файл с другим именем → новый документ.
2. Сравнение (ADD): при добавлении строки в spec_current не проверяется name_hash. Одна и та же услуга добавится дважды если пришла из двух разных допников с одинаковым содержанием.
3. Позиции: name_hash = md5(нормализованное_имя || date_start). Хеш есть, но используется только для UPDATE (поиск target_hash). При ADD — не проверяется.

Вопросы

1. Дедупликация документов при загрузке

Сейчас: delete_by_document(contract_id, filename) — только по совпадению имени.

Нужно ли:

• Сравнивать по хешу содержимого (sha256 original_bytes)?
• Сравнивать по elements_json?
• Или только по имени + предупреждение?

2. Дедупликация строк в spec_current (ADD → UPSERT)

Сейчас: ADD всегда INSERT. Если та же услуга приходит из другого допника — будет дубликат.

Предложение: перед INSERT проверять name_hash:

есть name_hash? → UPDATE (как обычный UPDATE)
нет           → INSERT

Вопросы:

• Правильно ли это? В каких случаях ADD должен ОСТАТЬСЯ INSERT даже при совпадении name_hash?
• Как обрабатывать если ADD и UPDATE приходят в одном наборе ops и пересекаются по name_hash?

3. Связанные краевые случаи

• Два допника с одинаковым содержанием, разные имена → сейчас: две обработки, возможны дубликаты. Как надо?
• Один допник добавляет услугу X, другой её же удаляет. Порядок имеет значение? Как обеспечить?
• ZIP содержит файлы с теми же именами что уже загружены. Перезаписывать? Пропускать? Спрашивать?
• Два одинаковых договора (разные имена) в одном батче. Как группировать?

Ожидаемый ответ

На каждый сценарий: как ДОЛЖНО быть и как проще всего реализовать сейчас (MVP). Приоритет: не сломать существующее поведение.

---

Ответ Opus

⚠️ Поправки к посылкам

1. «ADD всегда INSERT → дубликат» — неверно. spec_events.py уже делает UPSERT по (contract_id, name_hash): совпадение → UPDATE, иначе INSERT. Дублей в spec_current нет.
2. «name_hash = md5(имя ‖ date_start)» — неверно. Реально: sha256(name.strip().lower())[:16] — только имя. Услуги с одинаковым именем но разным периодом схлопываются.

---

Вопрос 1. Дедупликация документов при загрузке

Сейчас: delete_by_document(contract_id, filename) — по имени. Ошибки глотаются в try/except: pass. Хеша содержимого нет.

Как ДОЛЖНО быть:

• sha256(original_bytes) → documents.content_hash
• Идентичность в рамках договора/батча — по content_hash
• Сравнение по elements_json не нужно (нестабилен при смене парсера)
• Ошибки удаления логировать, не глотать

MVP:

• Колонка content_hash + индекс (contract_id/batch_id, content_hash)
• В store_document: если уже есть документ с таким хешем → пропустить, вернуть {duplicate_of: doc_id}

---

Вопрос 2. ADD → UPSERT

UPSERT по имени уже есть. Реальная проблема: last-write-wins — второй ADD молча перезаписывает первый (та же услуга, другая цена).

Как ДОЛЖНО быть:

• ADD = новая позиция. При коллизии ключа различать UPDATE vs реально разные позиции (одно имя, разный период)
• Ключ должен включать date_start/период

MVP — вариант B (рекомендован):

• Расширить ключ: _hash(name + "|" + str(date_start))
• Одна услуга в разные периоды = разные строки
• Риск: если допник меняет цену без смены date_start, LLM должен прислать UPDATE, а не ADD

---

Вопрос 3. Краевые случаи

a) Два допника с одинаковым содержанием, разные имена: Сейчас: два документа → два прогона LLM. Дублей в spec_current нет (UPSERT), но раздувается история. → MVP: дедуп по content_hash на загрузке (Вопрос 1).

b) ADD X, затем DELETE X — порядок: Применение по created_at или order_ids. Не по хронологии допников. → MVP: сортировать по doc_date (классификация уже извлекает): ORDER BY doc_date NULLS LAST, created_at.

c) ZIP с уже загруженными именами: → MVP: в рамках batch_id отсеивать по content_hash. Пропускать с предупреждением, не перезаписывать молча.

d) Два одинаковых договора в батче: → MVP: content_hash-дедуп решает «одинаковые»; для «разные файлы, один номер» — флаг конфликта в UI.

---

Сквозной MVP (что делать)

1. documents.content_hash + дедуп по нему на загрузке
2. Сортировка допников по doc_date
3. Опционально: date_start в name_hash

---

Ответ Opus — дополнительные засады (careless user)

🔴 Критичное — «юзер грузит хуйню»

1. ZIP-бомба / нет лимитов. unzip.py распаковывает всё без ограничений. Нужно: лимит ≤500 файлов, суммарный размер, проверка ratio.

2. Имена из ZIP без санитизации. Path-traversal не отсекается для файлов из архива. Нужно: та же проверка ..// + cp437→utf8.

3. try/except: pass глушит ошибки удаления. Минимум — логировать.

4. Ручной парс multipart по PK\x03\x04. Хрупко. Лучше cgi.FieldStorage.

🟠 Битый/мусорный контент

5. Supplement создаётся ДО парсинга. Битый файл → висячий supplement. Нужно: не создавать при ошибке.

6. Пустой парсинг = тихо пропадает. Скан/зашифрованный PDF → elements_json пуст → файл игнорируется без предупреждения.

7. Регистр/дубли имён. Договор.pdf vs договор.pdf — разные документы. → закрыто content_hash.

🟡 LLM возвращает мусор в ops

8. Пустой target_hash молча no-op. → нужно UNRESOLVED.

9. ADD с пустым именем схлопывается. → отбраковывать.

10. Неизвестный action молча игнорируется. Опечатка LLM → без сигнала.

11. Арифметика только логируется. sum ≠ price*qty — стоит флаг в UI.

🟢 Числа, даты, нормализация

12. Локализованные числа теряются. "1 000,50" → None. Нужна нормализация.

13. Даты без нормализации. 01.01.2026 vs 2026-01-01. Канонизировать перед хешем.

🔵 Конкурентность

14. Гонка двух прогонов. reset() без блокировки → каша. Нужен advisory-lock.

15. Нет идемпотентности батча. → закрыто content_hash.

Приоритет

1. Лимиты + санитизация ZIP (п.1,2,4)
2. content_hash-дедуп — ✅ уже сделано
3. Явный статус «не распознан» (п.5,6)
4. UNRESOLVED вместо тихих no-op (п.8,9,10)
5. Нормализация чисел/дат (п.12,13)
6. Advisory-lock (п.14) — при многопользовательности