Files
healthlog/docs/tasks/items/read-api.md
T
av 79331ac670 tasks: закрыт разбор и хранилище, начат спринт по чтению данных клиентами
- цель parsing-and-storage закрыта по своему критерию; незакрываемый остаток
  (новые формы от источника, ручные секции задним числом) переехал в тему
  parsing-completeness
- цель mcp поглощена целью read-api, переименованной в «Чтение данных
  клиентами»: адаптер — последний шаг того же направления, а не своё
- read-api-points разложена на конверт с точками, свёртку по сетке и
  тренировки с записями; спринт 2026-08-04 набран пятью задачами
2026-08-04 14:01:38 +03:00

27 lines
2.2 KiB
Markdown

# [goal] Чтение данных клиентами
- **Секция:** порядок
- **Зачем:** Данные видны только через sqlite на хосте — ни один из трёх потребителей, включая агента-медика, ничего прочитать не может
- **Теги:** decomposed
Потребители читают данные: точки с выбором слоя и свёрткой по сетке, тренировки
и записи, машиночитаемый контракт — и всё то же самое через MCP.
Выведена из шагов 5 и 7 плана. Идёт после каталога и рода агрегации намеренно:
без измеренного рода свёртка в ответе неотличима от угадывания, а ошибиться
здесь дорого — просуммировать нижний слой значит завысить втрое.
**MCP входит в эту цель, а не идёт отдельной.** Прежде их было две, и разделяла
их очередь: адаптер собственной логики не несёт, он переводит вызовы в те же
обработчики, и переводить было нечего. Очередь никуда не делась — она стала
порядком задач внутри цели, — а вот отдельная цель под адаптер описывала не
направление, а последний шаг этого же направления. Заказчик у обоих транспортов
один: три потребителя, из которых первый — агент.
## Завершение
Любой из трёх потребителей получает точки, тренировки и записи за период без
доступа к файлу базы; предел размера ответа объявлен, а не подразумевается;
агент-медик читает то же самое через MCP тем же токеном чтения, и собственной
логики адаптер не несёт.