# T-2026-001 — Приём заявок с vote: проверка ключа через Auth_server

> Часть кросс-проектной задачи **T-2026-001**.
> Overview: `C:\project\orchestrator\tasks\T-2026-001-vote-doc-orders\_overview.md`
> Проект: **Doc_manager** (doc.queo.ru)

## Зависимости
- Делать после: **Auth_server** (нужен verify-endpoint)
- Блокирует: сквозной тест
- Можно параллельно с: заданием Question

## Контекст
Endpoint `/api/incoming/orders` и раздел `/orders` уже реализованы. Меняем источник
истины по сайтам/ключам: вместо локальной таблицы Sites — проверка ключа
**централизованно через Auth_server**.

## Что сделать
- [ ] `/api/incoming/orders`: входящий `X-Site-Key` проверять через Auth `verify`
      (а не по локальной таблице Sites); из ответа брать идентичность сайта (siteId/domain).
- [ ] Кэшировать результат verify (короткий TTL), обрабатывать недоступность Auth
      (понятная ошибка/повтор, без потери заявки).
- [ ] Привязывать созданный Order к siteId из Auth.
- [ ] Локальный реестр Sites: вывести из обязательного пути приёма заявок
      (оставить как кэш/справочник или убрать — по ситуации, не ломая текущие данные).
- [ ] Проверить payload (customerName, customerInn, customerEmail, acceptedOfferAt, items[])
      и «Перевести в проект» (клиент по ИНН).

## Критерий готовности
- `curl` с ключом, выпущенным Auth, проходит verify и создаёт Order(new), видимый в `/orders`;
  без валидного ключа — отказ.

## Статус: TODO