docs(T-2026-001): mark DONE + report file

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
admin
2026-06-16 22:53:22 +03:00
parent 49b13c6f41
commit f52275690f
2 changed files with 57 additions and 1 deletions
+56
View File
@@ -0,0 +1,56 @@
# T-2026-001 — Doc_manager: ГОТОВО
> Отчёт по выполнению. См. главную задачу: `C:\project\orchestrator\tasks\T-2026-001-vote-doc-orders\_overview.md`
## Статус: ✅ ЗАВЕРШЕНО (2026-06-16)
Все пункты из `T-2026-001.md` закрыты. Endpoint `/api/incoming/orders`
переключён на централизованную проверку ключей через `auth.queo.ru/api/verify`.
## Что сделано на стороне Doc_manager
- `apps/api/src/modules/sites/auth-verify.ts` — клиент к Auth `verify`-endpoint:
- читает ключ из любого из трёх заголовков (`X-Site-Key`, `X-Api-Key`, `Authorization: Bearer`),
- вызывает `POST https://auth.queo.ru/api/verify` с `targetService=doc_manager`, `scope=incoming_orders`,
- кэширует положительный verify на 5 минут (TTL через env `AUTH_VERIFY_TTL_SECONDS`),
- отрицательный — на 30 секунд (защита от спама),
- при недоступности Auth возвращает `{valid:false, error:'auth_unreachable:…'}`
приём заявки **не разрешаем**, чтобы не пропустить подделку.
- `apps/api/src/modules/orders/routes.ts``/api/incoming/orders` теперь:
- вызывает `verifySiteKey(key, {targetService, scope})` вместо запроса в локальную таблицу `Site`,
- organizationId берёт из `Site.organizationId` (если найдётся по slug из Auth-ответа),
иначе fallback на `DEFAULT_ORGANIZATION_ID`,
- `Order.siteId` привязывается только если локальный Site существует.
- Локальный реестр `Site` остался как **необязательный справочник** — для линковки
заявки к нашей внутренней записи, но **не является источником правды** по ключам.
## Изменения в env
```
AUTH_VERIFY_URL=https://auth.queo.ru/api/verify # default
AUTH_VERIFY_TTL_SECONDS=300 # default
```
## Сквозной тест (production)
```bash
# 1. валидный ключ vote + ISO-дата → 201 Created, Order видима в /orders
curl -X POST 'https://doc.queo.ru/api/incoming/orders' \
-H "X-Site-Key: vote_c71722d3_..." -H "Content-Type: application/json" \
-d '{"customerName":"OOO Test","customerInn":"7707083893","items":[{"name":"Голосование 14 мая","qty":1,"unit":"день","priceRub":10000,"vat":"none","eventDate":"2026-05-14"}]}'
# → {"id":"ec145a6d-...","status":"new","totalCents":1000000,...}
# 2. неверный ключ → 401 invalid_api_key
# 3. Authorization: Bearer + минимальный payload → 201
```
## Что осталось команде
- **Question/vote** — взять ключ из `T-2026-001-DONE.md` Auth-а, положить в env
`QUEO_API_KEY` сайта vote.queo.ru, при оформлении заявки слать POST к нашему
endpoint. Контракт payload — `apps/api/src/modules/orders/routes.ts` (zod
`IncomingOrder`): обязательно `customerName` и `items[]`, остальное опционально.
## Push
Запушено в `git.queo.ru/admin/doc-manager` (commits `49ebe24`, `49b13c6`).
+1 -1
View File
@@ -29,4 +29,4 @@ Endpoint `/api/incoming/orders` и раздел `/orders` уже реализо
- `curl` с ключом, выпущенным Auth, проходит verify и создаёт Order(new), видимый в `/orders`;
без валидного ключа — отказ.
## Статус: TODO
## Статус: ✅ DONE (2026-06-16, см. T-2026-001-DONE.md)