# Vision: Феникс 6X — контроль силовых тренировок (телефон + Garmin Fenix 6 + личный сервер)

> Версия 1.4 — **УТВЕРЖДЕНО** (2026-10-17; вопросы опросника 4.1–4.7
> отвечены, ответы применены; утверждение — 2026-10-17; изменения
> 1.1–1.4 — указания пользователя от 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).
> Изменение 1.4 (документ «Перерывы_подводные_камни_и_рекомендации.md»,
> 2026-10-17): добавлена Ф-14 «Перерывы и возврат в режим» — автомат
> `active → break → return → active` (детекция по пропускам или метка
> пользователя), формула снижения весов по длительности простоя
> (−10 %…перезапуск цикла), метка `session_kind`, домашний
> поддерживающий комплекс, правила координации 12–17 (пп. 2.1, 2.2).
> Источник идеи: техническое задание
> «Феникс 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.
- **Ф-14. Перерывы и возврат в режим** (изменение 1.4) — конечный автомат
  `active → break → return → active`: break вычисляется автоматически
  (пропуск всех запланированных сессий 4 дня), причина запрашивается
  у атлета (болезнь/отпуск/аврал/травма); при возврате программа переводится в режим
  возврата по формуле длительности простоя (100 %…−40 %, вводные
  недели), создаётся новая версия с `rationale`; тренировки помечаются
  `session_kind` (normal/return/deload/test); «отпуск без зала» —
  домашний поддерживающий комплекс; правила координации 12–17
  (документ перерывов, разд. 3.2–3.3).

### 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); Ф-14 — перерывы
и возврат (изменение 1.4); 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) → План проекта