# ТЗ: Агент «Сверка договоров»

## Контекст

Есть договоры и дополнительные соглашения (допники) с клиентами. Файлы в форматах Word (.docx) и PDF. Данные строго конфиденциальны — обработка только на локальной модели (без внешних API).

---

## Задача 1: Разбор спецификации в структурированный вид

**Вход:** файл договора или допника (docx / pdf)

**Что делать:**
- Извлечь текст из файла
- Найти и распарсить спецификацию (таблица услуг/товаров)
- Вывести структуру: номер строки, наименование, количество, единица измерения, цена, сумма
- Если таблица не найдена или не поддаётся разбору — отметить задачу как **нерешаемую** с указанием причины (нет таблицы / нечитаемый PDF / нестандартный формат)

**Выход:** JSON или таблица со строками спецификации

---

## Задача 2: Кумулятивный статус договора по цепочке допников

**Вход:** базовый договор + список допников в хронологическом порядке

**Что делать:**
1. Взять спецификацию базового договора как начальное состояние
2. Для каждого допника определить тип изменений:
   - **Полная замена** — допник содержит новую полную спецификацию → заменить текущее состояние целиком
   - **Частичное изменение** — допник содержит только изменённые строки → идентифицировать строку (по наименованию / номеру позиции) и применить изменение
3. Строить историю состояний: дата допника → что изменилось → текущее состояние
4. Если строку из допника невозможно сопоставить с текущим состоянием — отметить эту строку как **нерешаемую** (нет совпадения), не применять изменение, продолжить обработку остальных

**Выход:**
- История изменений (timeline): дата / документ → изменения
- Итоговое состояние спецификации на последнюю дату

---

## Задача 3: Сопоставление позиций с каталогом услуг (опционально)

**Вход:** спецификация договора (из задачи 1) + каталог услуг (артикул + описание)

**Что делать:**
- По текстовому описанию строки спецификации найти ближайший артикул в каталоге
- Использовать семантическое сравнение (embedding / fuzzy match)
- Если уверенность совпадения ниже порога — отметить строку как **нерешаемую** (нет уверенного совпадения), не назначать артикул

**Выход:** спецификация с добавленным полем `артикул` (или пометкой `не определено`)

**Примечание:** задача реализуема только в части случаев. Приоритет — не ошибиться, а не охватить всё.

---

## Общие требования

| Требование | Описание |
|---|---|
| Модель | Только локальная (без внешних API) |
| Конфиденциальность | Файлы не покидают локальную среду |
| Обработка исключений | На каждом шаге — явная пометка нерешаемых подзадач с причиной. Не фантазировать, не домысливать |
| Форматы входа | .docx, .pdf |
| Формат выхода | JSON + человекочитаемый отчёт (md или html) |
| Логирование | Каждый шаг (файл → задача → результат / ошибка) фиксируется |

---

## Критерии успеха

- Структурированная спецификация получена или задача явно помечена как нерешаемая
- История изменений по допникам построена корректно
- Ни одно изменение не применено «наугад» без идентификации строки
- Итоговый отчёт читаем и проверяем вручную