av
bd832337df
- конверт и точки разложены на форму провода, точки за период и условный запрос; свёртка — на сетку, порог неполного ведра и предел размера ответа; тренировки и записи разъехались на два независимых маршрута - openapi-swagger разложена на спеку, гейт против расхождения и Swagger UI — все три вне набора, вместе с mcp-server - набор спринта 2026-08-04 — весь HTTP-слой чтения, восемь задач
2.6 KiB
Тренировки наружу
- Секция: ядро
- Зачем: Тренировки с маршрутами разобраны и лежат в витрине, а эндпоинтов нет — сценарий трекера не закрыт
- Теги: goal:read-api, sprint:2026-08-04
Трекер забирает тренировку одним пакетом вместе с маршрутом: GET /workouts за
период и GET /workouts/{id} поштучно.
Разбор и хранение тренировок сделаны (change 2026-08-02-trenirovki-i-zapisi),
эндпоинтов нет: тренировка с маршрутом лежит в витрине и наружу не отдаётся.
Второй сценарий паспорта — трекер тренировок — до тех пор не закрыт.
Это первый по-настоящему тяжёлый ответ проекта. Маршрут лежит блобом внутри тренировки, и общий предел размера ответа обязан распространяться и на него — иначе одна тренировка с длинным треком проходит мимо потолка, названного для точек. Отсюда же требование к списку: перечень за период не тянет треки, иначе неделя тренировок превращается в один неподъёмный ответ.
Конверт и форма провода наследуются, а не изобретаются.
Критерии приёмки
- тренировка отдаётся одним пакетом вместе с маршрутом — оракул: запрос к поднятому сервису на живом архиве
- список тренировок за период не тянет треки — оракул: тест, сравнивающий размер ответа списка с размером ответа одной тренировки
- тренировка с длинным треком подчиняется общему пределу размера ответа — оракул: тест на синтетическом треке за пределом
Рамки
Схема не трогается, данные только читаются. Берётся после конверта. Разворачивание маршрута в отдельную таблицу остаётся идеей и здесь не решается.