VEU.WathBody/1-docs/1-reqs/vision.md

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

Версия 1.0 — УТВЕРЖДЕНО (2026-10-17; вопросы опросника 4.1–4.7 отвечены, ответы применены; утверждение — 2026-10-17). Источник идеи: техническое задание «Феникс 6X» (Garmin Edition) от 17.10.2026 (Техническое задание.md); требование по стекам (Требование.md); обзор форматов (Форматы_тренировок_и_рекомендации.md); дизайн LLM-планирования (Архитектура_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) — 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, связь с результатами не анализируется).

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 (при включённом контуре) показывается диффом и не применяется без подтверждения; невалидное предложение отклоняется валидатором и не доходит до пользователя.

1.5. Положение о концепции проекта

Для атлета-любителя, который тренируется со штангой и гантелями и хочет вести учёт и контролировать нагрузку, не выпуская из рук снаряд, «Феникс 6X» — персональный комплекс «часы Garmin + телефон + личный сервер», который голосом записывает подходы, показывает кардионагрузку и отдых на запястье, ведёт тренировку по программе и автоматически собирает полный архив с пульсом в собственной базе; в отличие от блокнотов, приложений-дневников с ручным вводом и штатных экранов Garmin, наш продукт фиксирует результаты без рук, сверяет их с программой и на основании результатов корректирует следующие тренировки, храня данные у владельца, а не в чужом облаке.

1.6. Бизнес-риски

• БР-1. Доступ к Garmin Connect. Официальный Health API — партнёрская программа с одобрением Garmin (для личного проекта практически недоступна); неофициальные клиенты ломаются при изменениях Garmin. Потери × вероятность × контроль: средние × средняя × средняя. Смягчение: способ забора закреплён — неофициальный клиент (опросник 4.3); деградация — ручной экспорт .fit в папку импорта сервера.
• БР-2. Офлайн-распознавание речи в шумном зале (ганты, музыка). Смягчение: локальный движок с ограниченным словарём (вес, повторы, отдых), голосовое подтверждение каждой команды, правка вручную за ≤ 2 касания (КУ-1).
• БР-3. Ограничения Connect IQ на Fenix 6 (память приложения, тип поля данных). Смягчение: минимальное поле данных, метрики — штатными источниками платформы.
• БР-4. Ограниченный канал телефон ↔ часы в реальном времени (companion-канал Connect IQ, не прямой BLE). Смягчение: часы автономны (ТЗ п. 2.2), телефон показывает то, что канал передаёт; потеря канала не влияет на запись тренировки часами.
• БР-5. Корректировка программ «не в тему». Автоматические рекомендации без достаточной истории могут вредить (перегрузка). Смягчение (дизайн LLM-планирования): жёсткие методологические лимиты валидатора (рост веса ≤ +5 %/нед, объём ≤ ±20 %, делоад не реже 6 недель), человеко-машинный контур — дифф с «Принять / Изменить / Отклонить», бюджет доверия только для микроправок ±5 %; LLM подключается после накопления истории (порядок внедрения).
• БР-6. Не-разработка: результаты теряются и не анализируются, тренировки проходят без плана и контроля кардионагрузки, прогресс не управляем.

1.7. Предположения и зависимости

• Предположение П-1. Часы Garmin Fenix 6 носятся на каждой тренировке; смартфон обычно находится в зоне доступа микрофона (сумка, подставка), но его присутствие и связь с ним не обязательны: тренировка фиксируется часами и без телефона.
• Предположение П-2. Вес и повторения выражаются целыми числами; словарь команд ограничен набором ТЗ (подход/вес/отдых, активация) — достаточно офлайн-модели малого словаря.
• Предположение П-3. Личный сервер (VPS или домашний) доступен, на нём устанавливаются HTTPS и PostgreSQL.
• Зависимость З-1. Стандарт разработки std1 (I:\Kit\Kit.DevAi\std1): процесс, правила; серверная часть — C# / .NET 10, PostgreSQL, Npgsql (решение — Требование.md).
• Зависимость З-2. Аккаунт Garmin Connect; учётные данные/токен — в конфигурации сервера, не в коде.
• Зависимость З-3. Connect IQ SDK (Monkey C) и устройство 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).
• Ф-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. Веб-интерфейс сервера — таблица истории тренировок, выгрузка в 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).

2.2. Объём первоначально запланированной версии

Состав версии 1.0 (решения — опросники 4.4 и 4.6): v1.0 = полный MVP-цикл ТЗ (Ф-1–Ф-9) + программы: Ф-10, Ф-11 и правила прогрессии (основа Ф-12) — шаг 1 порядка внедрения LLM-планирования, без LLM; 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): LLM-планирование — еженедельные предложения с валидатором и дифф-подтверждением, журнал llm_calls (шаг 2 порядка внедрения; опросник 4.6); wake-word «Феникс, записывай» (опросник 4.5); iOS-версия телефонного приложения (опросник 4.2); экспорт тренировок из приложения в FIT; доставка программ на часы (FIT workout через Garmin Connect — документ форматов, п. 3/5.3).
• v2.x: мезоцикловое планирование LLM, схема «генератор+ревьюер», опрос RPE после тренировки, бюджет доверия (шаг 3); аналитика прогресса (тоннаж, динамика по упражнениям, пульсовые тренды), шифрование архива, напоминания о тренировках.
• v3+: виды спорта с треками — бег, вело (GPX, ввод темпа/дистанции; опросник 4.7); полная автоматизация периодизации без подтверждений.

Сроки последующих версий не фиксировались — привязываются к потребности.

2.4. Ограничения и исключения

Ограничения (принимаем как данность):

• личное использование: один пользователь, без авторизации и регистрации; телефон ↔ сервер — статический API-ключ;
• железо Fenix 6: экран 260×260 MIP без сенсора, управление кнопками, Connect IQ 4+; пульс в реальном времени на телефон — только через нативное приложение часов (ограничение Garmin);
• пульсофическая телеметрия силовых тренировок — только из FIT (TCX/GPX непригодны — документ форматов);
• один личный сервер; без оплаты внешних сервисов и подписок.

Исключения (система НЕ делает):

• не применяет изменения программы вне бюджета доверия (±5 %) без подтверждения пользователя; полностью автоматическая смена программы без подтверждений исключена (дизайн LLM-планирования, разд. 6);
• не является многопользовательской и не публикует данные в сторонние сервисы — только собственный сервер;
• не заменяет Garmin Connect — использует его как источник .fit;
• не изобретает собственные форматы обмена — FIT/JSON/CSV (документ форматов, п. 5.4);
• не пишет видео/фото и не снимает технику выполнения.

3. Бизнес-контекст

3.1. Профили заинтересованных лиц

• Пользователь-владелец (атлет, заказчик и единственный пользователь в одном лице). Ценность: ничего не теряется, тренировки идут по программе, прогресс управляем; вероятное отношение — соавтор требований. Важные функции: все — Ф-1–Ф-12.
• 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. Утверждение

• На все вопросы опросника получены ответы (2026-10-17, вопросы 4.1–4.7)
• Vision утверждён пользователем (2026-10-17) → План проекта