673 lines
57 KiB
Markdown
673 lines
57 KiB
Markdown
# Vision: Феникс 6X — контроль силовых тренировок (телефон + Garmin Fenix 6 + личный сервер)
|
||
|
||
> Версия 1.3 — **УТВЕРЖДЕНО** (2026-10-17; вопросы опросника 4.1–4.7
|
||
> отвечены, ответы применены; утверждение — 2026-10-17; изменения
|
||
> 1.1–1.3 — указания пользователя от 2026-10-17).
|
||
> Изменение 1.1: серверная часть
|
||
> поддерживает нескольких атлетов — у каждого свои программы, профиль
|
||
> и данные, с собственных телефона и часов (пп. 2.2, 2.4, 3.1);
|
||
> саморегистрации нет — учётные записи и API-ключи создаёт владелец
|
||
> сервера. Приложение на телефоне при этом не меняется (одно устройство —
|
||
> один атлет); часы поддерживаются различные: одно поле данных
|
||
> (Connect IQ) собирается под разные модели Garmin, серверу источник
|
||
> .fit безразличен (пп. 2.2, 2.4).
|
||
> Изменение 1.2: веб-интерфейс сервера — административная консоль
|
||
> владельца: просмотр тренировок и отчётов всех атлетов, корректировка
|
||
> программ (версии, смена активной), управление атлетами (Ф-9, п. 2.2);
|
||
> атлеты смотрят свои данные только на телефоне — веб-доступа для них
|
||
> нет.
|
||
> Изменение 1.3 (метрики тренировок и самоконтроля, документ
|
||
> «Метрики_тренировок_и_самоконтроля.md», 2026-10-17): добавлена Ф-13
|
||
> «Самоконтроль и допуск к тренировке» — дневник телеметрии (пульс
|
||
> покоя, АД, вес, талия, сон, самочувствие), предтренировочный допуск
|
||
> (пороги АД/пульса), RPE и боль в колене по сетам; правила
|
||
> координации Ф-12 расширены 11 детерминированными правилами по книгам
|
||
> (пп. 2.2, 2.3, 3.3).
|
||
> Источник идеи: техническое задание
|
||
> «Феникс 6X» (Garmin Edition) от 17.10.2026
|
||
> ([Техническое задание.md](../../Техническое%20задание.md)); требование
|
||
> по стекам ([Требование.md](../../Требование.md)); обзор форматов
|
||
> ([Форматы_тренировок_и_рекомендации.md](../../Форматы_тренировок_и_рекомендации.md));
|
||
> дизайн LLM-планирования
|
||
> ([Архитектура_LLM_планирования_тренировок.md](../../Архитектура_LLM_планирования_тренировок.md));
|
||
> дополнения пользователя в чате от 2026-10-17 (офлайн-first,
|
||
> программы тренировок).
|
||
> Черновик сформирован по навыку sd-vision (`_skills\sd-vision\SKILL.md`);
|
||
> процесс шага 1 — `_rules\sd\sd-init.md` стандарта std1
|
||
> (каноническое расположение — `I:\Kit\Kit.DevAi\std1`).
|
||
|
||
## 1. Бизнес-требования
|
||
|
||
### 1.1. Исходные данные
|
||
|
||
Задача поставлена техническим заданием от 17.10.2026 (структурированное,
|
||
с перечнем MVP из 9 позиций) и требованием по стекам:
|
||
|
||
- серверная часть разрабатывается по стандарту std1
|
||
([Требование.md](../../Требование.md)) — C# / .NET 10, PostgreSQL;
|
||
- часть на часах и телефоне — на подходящем стеке с учётом правил
|
||
разработки, принятых в организации.
|
||
|
||
Дополнения пользователя (чат, 2026-10-17):
|
||
|
||
- приложение на телефоне должно полноценно работать без интернета;
|
||
синхронизация с сервером выполняется автоматически при появлении связи
|
||
(в ТЗ заложено — п. 5.2, подтверждено как базовый принцип);
|
||
- главное — отслеживание результатов и **контроль исполнения
|
||
рекомендуемой программы тренировки**;
|
||
- будут **формироваться программы тренировок и корректироваться**
|
||
на основании полученных результатов.
|
||
|
||
Материалы:
|
||
|
||
- обзор форматов импорта/экспорта от 17.10.2026 — фиксирует FIT как
|
||
основной формат (сообщения `Set` — подходы, `Lap` — круги, дискретный
|
||
пульс), импорт FIT/TCX/GPX как fallback, JSON — внутреннее хранение
|
||
и API, CSV — отчётные выгрузки; TCX и GPX для силовых данных
|
||
непригодны (теряют подходы/вес/повторения);
|
||
- дизайн LLM-планирования от 17.10.2026 — ключевое решение: **LLM —
|
||
планировщик, код — источник истины**. Программа — версионированный
|
||
JSON-документ строгой схемы в БД сервера (версии неизменяемы,
|
||
упражнения — только по ID из библиотеки); LLM только предлагает
|
||
изменения структурным JSON, детерминированный валидатор проверяет
|
||
их по схеме и методологическим лимитам, применение — через дифф
|
||
с подтверждением пользователя (бюджет доверия для микроправок ±5 %).
|
||
Два контура: микроправки прогрессии после каждой тренировки — правила
|
||
(код, без LLM, работают офлайн); еженедельные и мезоцикловые
|
||
предложения — LLM (structured output) с офлайн-fallback на правила.
|
||
Метрики (adherence, тоннаж, оценочный 1ПМ, пульс-метрики) считает
|
||
детерминированный MetricsEngine — LLM сырые данные не видит. Порядок
|
||
внедрения: шаг 1 — ProgramStore + правила + метрики (без LLM),
|
||
шаг 2 — еженедельный LLM, шаг 3 — мезоциклы и «генератор+ревьюер».
|
||
(Упоминание FastAPI в документе — иллюстративное: стек сервера
|
||
закреплён Требованием — std1, C#/.NET 10; для взаимодействия с LLM
|
||
в std1 есть правила области `c-llm`.)
|
||
|
||
Архитектурная данность ТЗ (п. 2.2): Garmin не позволяет сторонним
|
||
телефонным приложениям получать пульс с часов в реальном времени через
|
||
стандартный Bluetooth — на часах нужно нативное приложение (Connect IQ,
|
||
Monkey C); полная запись тренировки ведётся самими часами, источник
|
||
архивных данных — облако Garmin Connect.
|
||
|
||
Что уже есть: часы Garmin Fenix 6 (Connect IQ 4+, пульсометр Elevate
|
||
Gen 3, экран 260×260 MIP, управление кнопками), смартфон, аккаунт
|
||
Garmin Connect, личный сервер; стандарт разработки std1 (процесс из
|
||
7 шагов, правила C#/.NET 10 + PostgreSQL, навыки).
|
||
|
||
### 1.2. Возможности бизнеса
|
||
|
||
Продукт автоматизирует путь «подход в зале → зафиксированный результат →
|
||
выполнение программы → скорректированная следующая программа»:
|
||
|
||
- фиксация подходов без рук: голосом («Подход 120 на 8», «Вес 80»,
|
||
«Отдых 90 секунд») с голосовым подтверждением — телефон можно не
|
||
трогать между подходами;
|
||
- контроль кардионагрузки в реальном времени на запястье: крупный пульс,
|
||
цветовые зоны, таймер отдыха, вибрация — телефон остаётся в сумке;
|
||
- контроль исполнения программы: перед тренировкой задан план
|
||
(упражнения, подходы, веса), во время — подсказка «что сейчас по
|
||
плану», после — отчёт «план/факт»;
|
||
- программы тренировок формируются и корректируются на основании
|
||
накопленных результатов — без ручного анализа таблиц;
|
||
- полный архив: на телефоне (локальная БД, работает офлайн), на личном
|
||
сервере (из треков .fit с дискретным пульсом и метками подходов),
|
||
выгрузка в CSV;
|
||
- среда использования — спортзал (перчатки, влага, шум): крупные зоны
|
||
касания, тёмная тема, управление часами кнопками.
|
||
|
||
Типичный сценарий: пользователь открывает на телефоне сегодняшнюю
|
||
программу → запускает на часах профиль «Силовая» → выполняет подходы,
|
||
фиксируя результаты голосом, часы показывают пульс, зону и отдых →
|
||
по завершении тренировка записана локально, отчёт «план/факт» готов →
|
||
при появлении интернета данные сами уходят на сервер; сервер дополнительно
|
||
забирает .fit из Garmin Connect и пополняет архив → по накопленным
|
||
результатам корректируется следующая программа.
|
||
|
||
### 1.3. Бизнес-цели
|
||
|
||
- **БЦ-1.** Каждый подход фиксируется голосом: от окончания фразы до
|
||
голосового подтверждения ≤ 5 с, без касания телефона (сейчас: заметки
|
||
в телефоне/блокноте между подходами — руки заняты, данные разбредаются).
|
||
- **БЦ-2.** Пульс, зона нагрузки и отдых отслеживаются на запястье без
|
||
обращений к телефону в течение подхода и отдыха (сейчас: штатные экраны
|
||
Garmin не связаны с учётом подходов, пульс не контролируется по зонам).
|
||
- **БЦ-3.** Тренировки идут по программе: перед тренировкой задан план,
|
||
по завершении виден отчёт «план/факт» (сейчас: программа — в голове
|
||
или в заметках, отклонения не фиксируются).
|
||
- **БЦ-4.** Ни одна зафиксированная тренировка не теряется при обрывах
|
||
любых связей — часы ↔ телефон и телефон ↔ интернет: часы пишут
|
||
тренировку полностью автономно, телефон фиксирует подходы без часов
|
||
и без сети, 100 % данных досылается при восстановлении (локальные
|
||
очереди, идемпотентность, сопоставление по времени — ТЗ п. 5.1) —
|
||
сейчас: ручные записи не восстанавливаются вовсе.
|
||
- **БЦ-5.** Полный архив с пульсом по подходам появляется на личном
|
||
сервере ≤ 30 минут после завершения тренировки, без ручных действий;
|
||
следующая программа формируется/корректируется на его основе
|
||
(сейчас: треки остаются в Garmin Connect, связь с результатами
|
||
не анализируется).
|
||
- **БЦ-6.** Нагрузка безопасна: каждая силовая тренировка проходит
|
||
предстартовый допуск (АД, пульс) — красные флаги (АД > 150/90,
|
||
пульс сидя > 90) ведут к отмене или замене лёгким кардио; признаки
|
||
перетренированности (пульс покоя +8 уд/мин два дня, самочувствие ≤ 2)
|
||
автоматически снижают план следующей тренировки (изменение 1.3,
|
||
документ метрик). (Сейчас: допуск определяется «на глазок».)
|
||
|
||
### 1.4. Критерии успеха
|
||
|
||
- **КУ-1.** Контрольная тренировка (≥ 4 упражнения, ≥ 16 подходов):
|
||
≥ 90 % голосовых команд распознаны офлайн с первого раза и подтверждены;
|
||
ошибочные правятся за ≤ 2 касания.
|
||
- **КУ-2.** На часах в профиле «Силовая»: пульс обновляется, цвет зоны
|
||
меняется по порогам 50/70/85 % от максимальной ЧСС, кнопка Lap
|
||
фиксирует подход; сохранённый .fit содержит дискретный пульс и метки
|
||
кругов/подходов.
|
||
- **КУ-3.** Тест обрыва: выключение Bluetooth и интернета в середине
|
||
тренировки не блокирует запись (подходы помечаются «Локально»);
|
||
после восстановления все данные сходятся без дублей — повторная
|
||
отправка не создаёт копий (идемпотентность).
|
||
- **КУ-4.** Скрипт сервера забирает .fit из Garmin Connect и сохраняет
|
||
в БД структурированные данные (пульс, круги/подходы, время); таблица
|
||
истории открывается в веб-интерфейсе, CSV выгружается.
|
||
- **КУ-5.** По тренировке с заданной программой формируется отчёт
|
||
«план/факт»: упражнение, подходы, веса — план против факта; на экране
|
||
активной тренировки видна текущая позиция программы.
|
||
- **КУ-6.** Правила прогрессии работают без LLM и сети: закрыл все
|
||
подходы при RPE ≤ 7 → вес на следующее занятие +2,5 кг; не дотянул
|
||
2 подхода → −5 %. Предложение LLM (при включённом контуре) показывается
|
||
диффом и не применяется без подтверждения; невалидное предложение
|
||
отклоняется валидатором и не доходит до пользователя.
|
||
- **КУ-7.** Тест красного флага: при введённом АД 160/100 приложение
|
||
не позволяет начать силовую тренировку и предлагает прогулку;
|
||
при RPE ≥ 9 в двух подходах правила формируют draft со снижением
|
||
веса −5 %; при пульсе покоя +8 уд/мин два дня подряд следующая
|
||
тренировка в плане помечается лёгкой (изменение 1.3).
|
||
|
||
### 1.5. Положение о концепции проекта
|
||
|
||
Для атлета-любителя, который тренируется со штангой и гантелями и хочет
|
||
вести учёт и контролировать нагрузку, не выпуская из рук снаряд,
|
||
**«Феникс 6X»** — персональный комплекс «часы Garmin + телефон + личный
|
||
сервер», который голосом записывает подходы, показывает кардионагрузку
|
||
и отдых на запястье, ведёт тренировку по программе и автоматически
|
||
собирает полный архив с пульсом в собственной базе; в отличие от
|
||
блокнотов, приложений-дневников с ручным вводом и штатных экранов
|
||
Garmin, наш продукт фиксирует результаты без рук, сверяет их с программой
|
||
и на основании результатов корректирует следующие тренировки, храня
|
||
данные у владельца, а не в чужом облаке.
|
||
|
||
### 1.6. Бизнес-риски
|
||
|
||
- **БР-1. Доступ к Garmin Connect.** Официальный Health API —
|
||
партнёрская программа с одобрением Garmin (для личного проекта
|
||
практически недоступна); неофициальные клиенты ломаются при изменениях
|
||
Garmin. Потери × вероятность × контроль: средние × средняя × средняя.
|
||
Смягчение: способ забора закреплён — неофициальный клиент (опросник
|
||
4.3); деградация — ручной экспорт .fit в папку импорта сервера.
|
||
- **БР-2. Офлайн-распознавание речи в шумном зале** (ганты, музыка).
|
||
Смягчение: локальный движок с ограниченным словарём (вес, повторы,
|
||
отдых), голосовое подтверждение каждой команды, правка вручную
|
||
за ≤ 2 касания (КУ-1).
|
||
- **БР-3. Ограничения Connect IQ и разнородность часов** (память
|
||
приложения, разные экраны/возможности моделей). Смягчение:
|
||
минимальное поле данных, метрики — штатными источниками платформы;
|
||
переносимый код + конфигурации сборки под модели (изменение 1.1);
|
||
якорное устройство — Fenix 6.
|
||
- **БР-4. Ограниченный канал телефон ↔ часы в реальном времени**
|
||
(companion-канал Connect IQ, не прямой BLE). Смягчение: часы автономны
|
||
(ТЗ п. 2.2), телефон показывает то, что канал передаёт; потеря канала
|
||
не влияет на запись тренировки часами.
|
||
- **БР-5. Корректировка программ «не в тему».** Автоматические
|
||
рекомендации без достаточной истории могут вредить (перегрузка).
|
||
Смягчение (дизайн LLM-планирования): жёсткие методологические лимиты
|
||
валидатора (рост веса ≤ +5 %/нед, объём ≤ ±20 %, делоад не реже
|
||
6 недель), человеко-машинный контур — дифф с «Принять / Изменить /
|
||
Отклонить», бюджет доверия только для микроправок ±5 %; LLM
|
||
подключается после накопления истории (порядок внедрения).
|
||
- **БР-6. Не-разработка:** результаты теряются и не анализируются,
|
||
тренировки проходят без плана и контроля кардионагрузки, прогресс
|
||
не управляем.
|
||
|
||
### 1.7. Предположения и зависимости
|
||
|
||
- **Предположение П-1.** Часы Garmin (Connect IQ) носятся на каждой
|
||
тренировке; смартфон обычно находится в зоне доступа микрофона
|
||
(сумка, подставка), но его присутствие и связь с ним не обязательны:
|
||
тренировка фиксируется часами и без телефона.
|
||
- **Предположение П-2.** Вес и повторения выражаются целыми числами;
|
||
словарь команд ограничен набором ТЗ (подход/вес/отдых, активация) —
|
||
достаточно офлайн-модели малого словаря.
|
||
- **Предположение П-3.** Личный сервер (VPS или домашний) доступен,
|
||
на нём устанавливаются HTTPS и PostgreSQL.
|
||
- **Зависимость З-1.** Стандарт разработки std1 (`I:\Kit\Kit.DevAi\std1`):
|
||
процесс, правила; серверная часть — C# / .NET 10, PostgreSQL, Npgsql
|
||
(решение — [Требование.md](../../Требование.md)).
|
||
- **Зависимость З-2.** Аккаунт Garmin Connect; учётные данные/токен —
|
||
в конфигурации сервера, не в коде.
|
||
- **Зависимость З-3.** Connect IQ SDK (Monkey C) и целевые устройства
|
||
Garmin для сборки и отладки части часов; список моделей — открытый
|
||
вопрос шага 4 (якорь — Fenix 6).
|
||
- **Зависимость З-4.** Garmin FIT SDK (официальный, бесплатный, есть
|
||
порт для C#) — парсинг .fit на сервере; Garmin может изменять
|
||
интерфейсы Garmin Connect — риск БР-1.
|
||
- **Зависимость З-5.** Офлайн-движок распознавания речи для Android
|
||
(кандидаты — Vosk / sherpa-onnx; конкретный выбор — шаг 5 процесса).
|
||
- **Зависимость З-6.** Провайдер LLM API (structured output / function
|
||
calling) для еженедельного планирования на сервере; вызовы редкие
|
||
(раз в неделю + мезоцикл), ключ — в конфигурации сервера; при
|
||
недоступности — офлайн-fallback на правила (дизайн LLM-планирования,
|
||
разд. 7); правила взаимодействия — std1 `c-llm`.
|
||
|
||
## 2. Рамки и ограничения проекта
|
||
|
||
### 2.1. Основные функции
|
||
|
||
- **Ф-1. Голосовой учёт подходов (телефон)** — офлайн-распознавание
|
||
команд («Подход 120 на 8», «Вес 80», «Отдых 90 секунд»), голосовое
|
||
подтверждение, автосохранение в текущую тренировку; активация в v1 —
|
||
кнопкой на экране (решение — опросник 4.5), wake-word — v2.
|
||
- **Ф-2. Кардиоконтроль на часах** — в тренировке «Силовая»: крупный
|
||
текущий пульс, средний пульс за подход, время под нагрузкой, цветовая
|
||
индикация зон (50/70/85 %), фиксация конца подхода кнопкой Lap,
|
||
виброотклик; часы автономно пишут трек пульса и нажатия (форма —
|
||
поле данных в профиле «Силовая», решение — опросник 4.1); одно
|
||
поле данных собирается под разные модели Garmin (изменение 1.1).
|
||
- **Ф-3. Экран активной тренировки (телефон)** — текущий пульс (значение
|
||
и график за подход), таймер отдыха с цветовой индикацией, текущая
|
||
позиция программы (Ф-11), статусы связи с часами и сетью.
|
||
- **Ф-4. Библиотека упражнений** — редактируемый список: добавление,
|
||
удаление, переименование.
|
||
- **Ф-5. История тренировок (телефон)** — завершённые тренировки: дата,
|
||
средний пульс, упражнения; офлайн — из локальной БД.
|
||
- **Ф-6. Профиль и зоны пульса** — пол, возраст, вес (ввод однократно)
|
||
→ расчёт зон; зоны используются телефоном и часами.
|
||
- **Ф-7. Офлайн-учёт и автосинхронизация** — все данные сначала
|
||
в локальную БД телефона; обрывы Bluetooth/интернета не блокируют
|
||
запись (пометка «Локально»); при появлении связи данные досылаются
|
||
на сервер (очередь `sync_pending`, идемпотентность, тихие баннеры
|
||
статуса).
|
||
- **Ф-8. Серверный архив** — забор .fit из Garmin Connect неофициальным
|
||
клиентом под учётной записью владельца по расписанию (решение —
|
||
опросник 4.3; деградация — ручной экспорт .fit в папку импорта),
|
||
парсинг FIT (Session, Lap, Record, Set — Garmin FIT SDK), сохранение
|
||
в собственную БД; REST API со статическим ключом;
|
||
импорт FIT/TCX/GPX как fallback (документ форматов).
|
||
- **Ф-9. Веб-интерфейс сервера** — административная консоль владельца
|
||
(изменение 1.2): просмотр тренировок всех атлетов (таблица,
|
||
карточка, план/факт) и метрик, выгрузка в CSV; корректировка
|
||
программ — создание и правка версий, смена активной; управление
|
||
атлетами — заведение учётных записей и ключей. Атлеты работают
|
||
только через телефон.
|
||
- **Ф-10. Программа тренировок** — программа как версионированный
|
||
JSON-документ (недели → тренировки → упражнения по ID библиотеки →
|
||
подходы-план: вес, повторения, RPE, отдых); версии неизменяемы,
|
||
выполненные тренировки ссылаются на версию (дизайн LLM-планирования,
|
||
разд. 2); составление в v1 — вручную пользователем, LLM-предложения —
|
||
v2 (решение — опросник 4.6).
|
||
- **Ф-11. Контроль исполнения программы** — подсказка «что сейчас
|
||
по плану» на экране активной тренировки; отчёт «план/факт» по
|
||
завершённой тренировке (КУ-5).
|
||
- **Ф-12. Корректировка программы по результатам** — гибрид: после
|
||
каждой тренировки микроправки прогрессии детерминированными правилами
|
||
(без LLM, работают офлайн); еженедельные/мезоцикловые предложения —
|
||
LLM со структурным выводом, обязательный детерминированный валидатор
|
||
(схема + методологические лимиты), применение — дифф с подтверждением
|
||
пользователя (бюджет доверия для микроправок ±5 %); офлайн-fallback —
|
||
правила; расчёт метрик (adherence, тоннаж, 1ПМ, пульс-метрики) —
|
||
детерминированный MetricsEngine (дизайн LLM-планирования, разд. 3–7).
|
||
- **Ф-13. Самоконтроль и допуск к тренировке** (изменение 1.3) —
|
||
дневник телеметрии (утренний пульс покоя, АД, вес тела, талия, сон,
|
||
самочувствие 1–5); предтренировочный допуск: пульс сидя > 90 уд/мин
|
||
или АД > 150/90 → предложение перенести/отменить тренировку,
|
||
АД 140–150/90–95 → только лёгкое кардио; по сетам — RPE и боль
|
||
в колене (0–10) для упражнений на ноги; после тренировки — время
|
||
возврата пульса (из .fit). Источник порогов и правил — документ
|
||
метрик («Метрики_тренировок_и_самоконтроля.md», Жижин, Аттия,
|
||
МакРоберт, CDC); состав v1 — MVP-приоритет документа (его п. 5):
|
||
дневник-минимум + правила координации 1–6; утренняя телеметрия
|
||
полностью и правила 7–10 — v2, контрольные тесты — v3.
|
||
|
||
### 2.2. Объём первоначально запланированной версии
|
||
|
||
Состав версии 1.0 (решения — опросники 4.4 и 4.6, изменение 1.3):
|
||
**v1.0 = полный MVP-цикл ТЗ (Ф-1–Ф-9) + программы: Ф-10, Ф-11 и правила
|
||
прогрессии/координации (основа Ф-12) — шаг 1 порядка внедрения
|
||
LLM-планирования, без LLM; Ф-13 в MVP-составе документа метрик
|
||
(дневник-минимум, допуск по АД/пульсу, правила 1–6); LLM-контур
|
||
Ф-12 — v2**.
|
||
Разработка — в порядке перечня MVP ТЗ: часы → связь с телефоном → экран
|
||
тренировки → голосовой ввод → локальная БД → сервер → забор .fit →
|
||
синхронизация → история и веб.
|
||
|
||
Нефункциональные требования v1, устанавливаемые сразу (влияют на
|
||
архитектуру):
|
||
|
||
- офлайн-first: телефон полноценно работает без интернета; синхронизация
|
||
— автоматически при появлении связи (решение пользователя, 2026-10-17);
|
||
- независимость частей: связь часы ↔ телефон может отсутствовать —
|
||
часы пишут тренировку полностью автономно (ТЗ п. 2.2), телефон ведёт
|
||
учёт голосом без часов; при восстановлении связи данные сопоставляются
|
||
по времени (ТЗ п. 5.1); ни одна часть не блокирует другую;
|
||
- идемпотентность API и локальных очередей — дубликаты исключаются
|
||
(КУ-3);
|
||
- форматы (документ форматов, 17.10.2026): FIT — основной формат обмена
|
||
с экосистемой Garmin; импорт сервера — FIT/TCX/GPX; внутреннее
|
||
хранение и API — JSON; CSV — только отчётные выгрузки; GPX для
|
||
силовых данных не используется;
|
||
- UI: тёмная тема по умолчанию, крупные зоны касания, ≤ 3–4 активных
|
||
элементов на экране во время подхода, крупный контрастный шрифт
|
||
цифр (Roboto/Inter);
|
||
- серверная часть — C# / .NET 10 + PostgreSQL по std1; платформа
|
||
телефона — нативный Android (Kotlin), iOS — v2 (опросник 4.2);
|
||
часть часов — Monkey C (Connect IQ, поле данных — опросник 4.1).
|
||
|
||
### 2.3. Объём последующих версий
|
||
|
||
- **v2** (состав по решениям опросников 4.5, 4.6; изменение 1.3):
|
||
LLM-планирование — еженедельные предложения с валидатором
|
||
и дифф-подтверждением, журнал `llm_calls` (шаг 2 порядка внедрения;
|
||
опросник 4.6); полная утренняя телеметрия и правила координации 7–10
|
||
(Ф-13); wake-word «Феникс, записывай» (опросник 4.5); iOS-версия
|
||
телефонного приложения (опросник 4.2); экспорт тренировок из
|
||
приложения в FIT; доставка программ на часы (FIT workout — документ
|
||
форматов, п. 3/5.3).
|
||
- **v2.x:** мезоцикловое планирование LLM, схема «генератор+ревьюер»,
|
||
опрос RPE после тренировки, бюджет доверия (шаг 3); аналитика
|
||
прогресса (тоннаж, динамика по упражнениям, пульсовые тренды),
|
||
шифрование архива, напоминания о тренировках.
|
||
- **v3+:** контрольные тесты (обхваты, пробы Руфье/Штанге—Генчи,
|
||
тест ходьбы) с напоминаниями, экспорт АД-журнала; трековые виды
|
||
спорта — бег, вело (GPX, опросник 4.7); полная автоматизация
|
||
периодизации без подтверждений.
|
||
|
||
Сроки последующих версий не фиксировались — привязываются к потребности.
|
||
|
||
### 2.4. Ограничения и исключения
|
||
|
||
Ограничения (принимаем как данность):
|
||
|
||
- использование без саморегистрации: учётные записи атлетов и API-ключи
|
||
создаёт владелец сервера; сервер поддерживает несколько атлетов —
|
||
у каждого свои программы, профиль и данные, с собственных телефона
|
||
и часов (изменение 1.1); клиентская часть (телефон + часы) —
|
||
одноатлетная: устройство принадлежит одному человеку;
|
||
- часы — модели Garmin с Connect IQ: одно поле данных собирается
|
||
под разные модели (размеры/разрешения экранов — конфигурации сборки
|
||
одного кода); якорное устройство v1 — Fenix 6 (260×260 MIP, кнопки),
|
||
добавление моделей — новой конфигурацией сборки без переделки кода
|
||
(перечень устройств v1+ — открытый вопрос шага 4);
|
||
- пульсофическая телеметрия силовых тренировок — только из FIT
|
||
(TCX/GPX непригодны — документ форматов);
|
||
- один личный сервер; без оплаты внешних сервисов и подписок.
|
||
|
||
Исключения (система НЕ делает):
|
||
|
||
- не применяет изменения программы вне бюджета доверия (±5 %) без
|
||
подтверждения пользователя; полностью автоматическая смена программы
|
||
без подтверждений исключена (дизайн LLM-планирования, разд. 6);
|
||
- не даёт саморегистрации и публичного доступа: работают только
|
||
атлеты, созданные владельцем сервера;
|
||
- не заменяет Garmin Connect — использует его как источник .fit;
|
||
- не изобретает собственные форматы обмена — FIT/JSON/CSV
|
||
(документ форматов, п. 5.4);
|
||
- не пишет видео/фото и не снимает технику выполнения.
|
||
|
||
## 3. Бизнес-контекст
|
||
|
||
### 3.1. Профили заинтересованных лиц
|
||
|
||
- **Пользователь-владелец (атлет, заказчик, владелец сервера).**
|
||
Ценность: ничего не теряется, тренировки идут по программе, прогресс
|
||
управляем; вероятное отношение — соавтор требований. Важные функции:
|
||
все — Ф-1–Ф-13.
|
||
- **Другие атлеты (изменение 1.1)** — тренируются по своим программам
|
||
со своих телефона и часов; данные изолированы в рамках сервера.
|
||
Важные функции: Ф-1–Ф-13 (кроме владения сервером).
|
||
- **Врач/кардиолог (внешний консультант, изменение 1.3).** Получает
|
||
АД-журнал и сведения о нагрузках (выгрузка CSV из веб-консоли);
|
||
в системе ничего не делает.
|
||
- **Garmin (внешняя платформа, не пользователь).** Источник SDK, .fit,
|
||
ограничений (БР-1, БР-3, БР-4); с системой ничего не делает.
|
||
|
||
### 3.2. Приоритеты проекта
|
||
|
||
- **Функции** — ведущий фактор: v1 закрывает цикл «программа →
|
||
тренировка без рук → архив → отчёт план/факт» целиком.
|
||
- **Качество** — ограничение: потеря данных тренировки недопустима
|
||
(офлайн-first, очереди, идемпотентность — БЦ-4, КУ-3).
|
||
- **Затраты** — ограничение: без платных сервисов и подписок; личный
|
||
сервер уже есть.
|
||
- **Кадры** — ограничение: фактически один разработчик (пользователь +
|
||
ИИ-агент).
|
||
- **График** — степень свободы: жёстких сроков нет.
|
||
|
||
### 3.3. Особенности развертывания
|
||
|
||
- **Часы:** приложение собирается через Connect IQ SDK и устанавливается
|
||
в dev-режиме (sideload); используется в каждом походе в зал в профиле
|
||
«Силовая».
|
||
- **Телефон:** установка личной сборкой в обход магазина; разрешения:
|
||
микрофон, Bluetooth, уведомления, фоновая работа; работает офлайн,
|
||
синхронизация — по появлении сети.
|
||
- **Сервер:** личный VPS/домашний сервер; HTTPS, PostgreSQL, скрипт
|
||
забора .fit по расписанию; учётные данные Garmin — в конфигурации
|
||
сервера (не в коде).
|
||
- **Инфраструктурные изменения:** создание БД на сервере, учётная запись
|
||
Garmin в конфигурации, место на сервере под архив (объём — шаг 5).
|
||
- Обучение не требуется: единственный пользователь — автор требований.
|
||
|
||
## 4. Опросник
|
||
|
||
### Вопрос 4.1. Форма приложения на часах
|
||
|
||
ТЗ (п. 2.2) называет два типа — «нативный виджет (Widget) или поле данных
|
||
(Data Field)», но её же основной сценарий: запуск штатного профиля
|
||
«Силовая», кастомное поле данных на экране, фиксация подхода кнопкой Lap,
|
||
автономная запись трека часами. Поле данных живёт внутри тренировки:
|
||
штатная запись .fit, штатный Lap, доступ к пульсу. Виджет работает вне
|
||
тренировки: трек не пишет и Lap не фиксирует — требование «часы сами пишут
|
||
трек пульса и нажатия кнопок» при виджете не выполняется, серверный
|
||
парсинг .fit (Ф-8) теряет источник.
|
||
|
||
**Варианты:**
|
||
1. **Поле данных (Data Field) в профиле «Силовая»** — трек, Lap и пульс
|
||
штатные, .fit полон (работает на Ф-8, КУ-2); ограничение — память
|
||
поля данных Connect IQ (БР-3).
|
||
2. **Виджет (Widget)** — отдельный экран вне тренировки; трек тренировки
|
||
не пишется — противоречит сценарию ТЗ.
|
||
3. **Оба** — плюс отдельная разработка виджета в v1.
|
||
|
||
**Рекомендую:** вариант 1 — единственная форма, при которой выполняется
|
||
сценарий ТЗ целиком; виджет ценности не добавляет.
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Форма приложения на часах закреплена: поле данных
|
||
(Data Field) в штатном профиле «Силовая». Отражено в Ф-2 (п. 2.1);
|
||
виджет — вне рамок (п. 2.4 не добавлялся — форма одна).
|
||
|
||
### Вопрос 4.2. Платформа и стек телефона
|
||
|
||
ТЗ (п. 4.1) заявляет Android 11+ / iOS 15+. Приложение личное — ведущий
|
||
фактор, каким телефоном атлет фактически пользуется. Ключевые нагрузки:
|
||
офлайн-распознавание речи (П-2, БР-2), Bluetooth, фоновая работа, локальная
|
||
БД. Требование.md разрешает телефону «подходящий стек» — правила std1
|
||
(C#) на телефонную часть не переносятся (они про сервер).
|
||
|
||
**Варианты:**
|
||
1. **Нативный Android (Kotlin; Room; офлайн-STT — Vosk / sherpa-onnx)** —
|
||
лучший контроль микрофона и фона, зрелый офлайн-STT; iOS — отдельная
|
||
разработка позже (v2).
|
||
2. **Кроссплатформа Flutter** — один код на Android+iOS сразу;
|
||
офлайн-STT и Bluetooth — через плагины, слой плагинов добавляет
|
||
хрупкость.
|
||
3. **.NET MAUI (C#)** — единый язык со стеком сервера; экосистема
|
||
офлайн-STT/Bluetooth — слабейшая из трёх.
|
||
|
||
**Рекомендую:** вариант 1, если телефон атлета — Android (укажите
|
||
фактическую модель/ОС в ответе); если нужен iOS с первого дня — вариант 2.
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Платформа телефона закреплена: нативный Android
|
||
(Kotlin; Room; офлайн-STT — Vosk / sherpa-onnx). iOS — v2 (п. 2.3).
|
||
Отражено в п. 2.2 (нефункциональные требования) и З-5 (п. 1.7).
|
||
|
||
### Вопрос 4.3. Способ забора .fit с Garmin Connect
|
||
|
||
Серверный контур (Ф-8) строится на файлах .fit — выбор формата верен
|
||
(документ форматов, п. 5.1); открыт вопрос канала доставки. Официальный
|
||
Garmin Health API — партнёрская программа: заявка, одобрение Garmin не
|
||
гарантировано (для личного проекта — практически недоступно), выгрузка
|
||
с задержкой. Неофициальные клиенты (семейство garminconnect) входят под
|
||
учётной записью владельца и скачивают .fit сразу после синхронизации
|
||
часов; ломаются при изменениях Garmin (БР-1, З-4).
|
||
|
||
**Варианты:**
|
||
1. **Официальный Health API** — надёжно и легально, но одобрение для
|
||
личного проекта маловероятно.
|
||
2. **Неофициальный клиент под учётной записью владельца** (скрипт на
|
||
сервере по расписанию) — автоматизм сегодня; риск поломки при
|
||
изменениях Garmin; пароль — в конфигурации сервера, не в коде.
|
||
3. **Ручной экспорт** — владелец скачивает .fit из веб-Garmin Connect
|
||
и кладёт в папку наблюдения сервера; ноль зависимости от API, но
|
||
ручное действие после каждой тренировки (против БЦ-5).
|
||
|
||
**Рекомендую:** вариант 2 — единственный автоматический, доступный сразу;
|
||
деградация при поломке — вариант 3 с той же папкой импорта.
|
||
|
||
**Ответ:** 2
|
||
|
||
**Что сделано:** Способ забора .fit закреплён: неофициальный клиент
|
||
Garmin Connect под учётной записью владельца, скрипт на сервере по
|
||
расписанию; деградация при поломке (БР-1) — ручной экспорт .fit в ту же
|
||
папку импорта сервера. Отражено в Ф-8 (п. 2.1), БР-1 (п. 1.6),
|
||
З-2/З-4 (п. 1.7), п. 3.3.
|
||
|
||
### Вопрос 4.4. Состав версии 1.0
|
||
|
||
Перечень MVP ТЗ (9 позиций) — от приложения на часах до веб-интерфейса
|
||
сервера. Клиентский контур (часы + телефон + голос + локальная БД + офлайн)
|
||
даёт ценность «без рук» сразу; серверный контур (забор .fit, БД, веб,
|
||
синхронизация) закрывает архив и аналитику по пульсу подходов (БЦ-5).
|
||
Требование.md включает серверную часть в проект по std1.
|
||
|
||
**Варианты:**
|
||
1. **v1.0 = полный MVP-цикл (Ф-1–Ф-9) + программы в составе по
|
||
опроснику 4.6** — разработка в порядке MVP ТЗ; клиент даёт ценность
|
||
до готовности сервера; v1 закрывает все бизнес-цели.
|
||
2. **v1.0 = клиентский контур (Ф-1–Ф-7), v1.1 = сервер и синхронизация
|
||
(Ф-8, Ф-9)** — более ранний первый релиз; БЦ-5 откладывается.
|
||
|
||
**Рекомендую:** вариант 1 — ТЗ определяет MVP целиком, серверная часть
|
||
уже включена в требование; порядок работ внутри v1 всё равно
|
||
«клиент раньше сервера».
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Состав v1.0 закреплён: полный MVP-цикл (Ф-1–Ф-9) +
|
||
программы в составе по опроснику 4.6 (Ф-1–Ф-11, LLM-контур Ф-12 — v2).
|
||
Отражено в п. 2.2; БЦ-5 достижим в v1.
|
||
|
||
### Вопрос 4.5. Активация голосового ввода
|
||
|
||
ТЗ (п. 2.1): «активация по голосовой команде (например, „Феникс,
|
||
записывай“) или нажатием кнопки на экране». Wake-word требует постоянного
|
||
прослушивания микрофона: в Android фоновый доступ к микрофону ограничен
|
||
(разрешения, остановка системой), в шумном зале — ложные срабатывания
|
||
и расход батареи; офлайн wake-word «Феникс» — отдельная модель. Кнопка
|
||
на экране — одно касание перед началом упражнения, далее все фразы
|
||
голосом: сама фиксация подходов остаётся «без рук» в обоих вариантах
|
||
(БЦ-1).
|
||
|
||
**Варианты:**
|
||
1. **v1 — активация кнопкой (крупная зона касания); wake-word — v2** —
|
||
быстрее и надёжнее в зале; цель «без рук» для подходов выполняется.
|
||
2. **Wake-word сразу в v1** — полное «без рук», но фоновые ограничения
|
||
Android, ложные срабатывания, БР-2 усугубляется.
|
||
|
||
**Рекомендую:** вариант 1 — активация кнопкой в v1, wake-word — v2.
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Активация голосового ввода закреплена: v1 — кнопкой
|
||
на экране (крупная зона касания); wake-word «Феникс, записывай» — v2
|
||
(п. 2.3). Отражено в Ф-1 (п. 2.1); БЦ-1 выполняется без wake-word.
|
||
|
||
### Вопрос 4.6. Глубина контура программ в v1.0
|
||
|
||
Дополнение пользователя (2026-10-17): главное — отслеживание результатов
|
||
и контроль исполнения рекомендуемой программы; программы формируются
|
||
и корректируются на основании результатов. Архитектура контура закреплена
|
||
дизайном LLM-планирования от 17.10.2026: ProgramStore с версионированным
|
||
JSON, метрики — детерминированный MetricsEngine, микроправки прогрессии —
|
||
правила (без LLM), LLM — еженедельные/мезоцикловые предложения через
|
||
валидатор и дифф-подтверждение, офлайн-fallback — правила. Документ
|
||
предлагает порядок внедрения: шаг 1 — ProgramStore + правила + метрики
|
||
(система полезна без LLM и накапливает данные), шаг 2 — еженедельный LLM,
|
||
шаг 3 — мезоциклы и «генератор+ревьюер». Открытым остаётся только,
|
||
сколько шагов войти в v1.0: ранний LLM предлагает «умные» корректировки
|
||
сразу, но без накопленной истории они опираются на малые данные (БР-5)
|
||
и оттягивают релиз базового цикла.
|
||
|
||
**Варианты:**
|
||
1. **v1 = шаг 1 (Ф-10, Ф-11, правила прогрессии, метрики); шаги 2–3 —
|
||
v2** — работающая система без внешнего LLM в первой версии; правила
|
||
микроправок не зависят от сети (КУ-6); рекомендации подключаются,
|
||
когда есть история (рекомендация самого дизайна, разд. 11).
|
||
2. **v1 = шаги 1–2 (плюс еженедельный LLM)** — полный контур сразу;
|
||
v1 вырастает на интеграцию LLM, журнал вызовов и дифф-UI.
|
||
3. **v1 = шаги 1–3** — вся глубина сразу; не рекомендована: максимум
|
||
риска при минимуме накопленных данных.
|
||
|
||
**Рекомендую:** вариант 1 — совпадает с порядком внедрения из дизайна
|
||
LLM-планирования; LLM-контур добавляется в v2 на реальной истории
|
||
тренировок.
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Глубина контура программ в v1.0 закреплена: шаг 1
|
||
порядка внедрения — ProgramStore (версионированный JSON), правила
|
||
прогрессии (основа Ф-12, без LLM — КУ-6), MetricsEngine, контроль
|
||
план/факт (Ф-10, Ф-11); LLM-контур (еженедельные предложения) — v2,
|
||
мезоциклы и «генератор+ревьюер» — v2.x (п. 2.3). Отражено в п. 2.2.
|
||
|
||
### Вопрос 4.7. Виды спорта: только силовые или шире
|
||
|
||
ТЗ определяет систему как приложение для **силовых** тренировок, и v1
|
||
опирается на это целиком: голосовой ввод «вес на повторов» (Ф-1), нативный
|
||
профиль «Силовая» на часах (опросник 4.1), парсинг `Set`/`Lap` из .fit
|
||
(Ф-8), программы с подходами-план «вес/повторения/RPE» (Ф-10–Ф-12).
|
||
При этом базовая механика универсальна: пульс, зоны, таймер, автономная
|
||
запись, офлайн-синхронизация вида спорта не требуют; документ форматов
|
||
отмечает GPX как задел «для будущего функционала бега/велосипеда».
|
||
Расширение затрагивает: ввод результатов (для бега — темп/дистанция
|
||
вместо вес/повторения), типы программ, парсинг телеметрии, второе
|
||
приложение на часах (профили «Бег»/«Вело»).
|
||
|
||
**Варианты:**
|
||
1. **v1 — только силовые; бег/вело — v3+ (как в п. 2.3)** — границы v1
|
||
не распухают; универсальные механизмы (пульс, офлайн, синхронизация)
|
||
с самого начала проектируются без привязки к виду спорта, чтобы
|
||
расширение не потребовало переделки.
|
||
2. **Виды спорта с треками (бег/вело) — v2** — раньше полный продукт,
|
||
но v1 вырастает на второй контур ввода, программ и парсинга.
|
||
3. **Система изначально мультиспортивная** (вид спорта — параметр) —
|
||
максимальная общность с первого дня; риск «недоделать всё сразу»
|
||
при одном разработчике.
|
||
|
||
**Рекомендую:** вариант 1 — ТЗ силовое, расширение закладывается
|
||
архитектурно (вид спорта — атрибут данных), но реализуется после
|
||
работающего силового контура.
|
||
|
||
**Ответ:** 1
|
||
|
||
**Что сделано:** Виды спорта закреплены: v1 и v2 — только силовые
|
||
тренировки; бег/вело (трековые виды, GPX) — v3+ (п. 2.3). Универсальные
|
||
механизмы (пульс, зоны, офлайн-учёт, синхронизация) с самого начала
|
||
проектируются без привязки к виду спорта.
|
||
|
||
## 5. Утверждение
|
||
|
||
- [x] На все вопросы опросника получены ответы (2026-10-17, вопросы 4.1–4.7)
|
||
- [x] Vision утверждён пользователем (2026-10-17) → План проекта
|