diff --git a/History/opus-dedup-2026-06-28.md b/History/opus-dedup-2026-06-28.md
new file mode 100644
index 0000000..4e2a66e
--- /dev/null
+++ b/History/opus-dedup-2026-06-28.md
@@ -0,0 +1,47 @@
+# Запрос 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). Приоритет: не сломать существующее поведение.