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). Приоритет: не сломать существующее поведение.