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