# Ревью документации №3 от 2026-10-17 — задания к исполнению > **Исполнитель:** агент сопровождения документации WatchBody. > **Источник:** третья архитектурная проверка документации шагов 1–6 > (после исполнения ревью №2, З-16…З-29, коммит `e674318` + рабочая > копия): сверка с исходной задачей (`Техническое задание.md`, > `Требование.md`), документами-рекомендациями и внутренняя > согласованность (requirements ↔ vision ↔ architecture ↔ tech-req ↔ > tables ↔ functions ↔ readme/plan). > **Уточнение владельца (чат, 2026-10-17):** программа тренировок > (`program-trenirovok.md` / `program-trenirovok.json`) — **импортируемый > пакет процесса эксплуатации**, назначается атлету индивидуально и > **не может быть нормативным источником документации разработки**. > В документах разработки на неё допустимы ссылки только как на > импортируемые данные атлета (формат/пример). > **Состояние репозитория на момент проверки:** коммит `e674318`, > ветка `main`; правки ревью №2 в рабочей копии, **не закоммичены** > (12 изменённых файлов; чек-лист ревью №2 «push выполнен после каждой > волны» — не соответствует факту, см. раздел 8). Также в рабочей > копии изменены корневые `program-trenirovok.md`/`.json` (v4→v5) и > добавлен `program-import.json` — это эксплуатационные данные, в > документационный коммит не включать; правку v4→v5 подтвердить у > владельца. > **Статусная модель заданий:** ⬜ не начато → 🔄 в работе → ✅ готово > (утверждено владельцем). Отметки — в разделе 6 по мере работы. > **Общие правила исполнения:** > 1. Правки вносятся в черновые версии текущей волны ревью №2 (они ещё > не утверждены): vision 1.5 (черновик), requirements 1.4, > tech-requirements 1.4, architecture 1.2, tables/functions — > новая редакция. Утверждение — одно на весь пакет > **Пользователь!** (d-dev-4). > 2. Содержание утверждённых документов меняется только в объёме > заданий; инварианты 🛡 не ослабляются; трассировка > «Ф → БЦ → КУ → версия» (раздел 6 requirements) сохраняется. > 3. Задание, зависящее от решения О-4 (раздел 1), не вносится до > выбора владельцем; остальные можно выполнять сразу. Если владелец > не выбрал — подготовить дифф по рекомендованному варианту и > вынести на утверждение. > 4. Код (`3-app\`, `2-db\`) не трогается — задание касается только > `1-docs\` и корневых `readme.md`/`plan.md`-упоминаний. > 5. Коммит и push — после утверждения пакета владельцем, **только > файлы `1-docs\` и корневой `readme.md`**; корневые > `program-trenirovok.*` и `program-import.json` в коммит не > включать (эксплуатационные данные). > 6. Исходные документы задачи в корне (`Техническое задание.md`, > документы-рекомендации, `program-trenirovok.*`) не редактируются > — это вход/эксплуатационные данные, а не документация разработки. ## 0. Сводка ревью №3 Исполнение ревью №2 подтверждено полностью: все задания З-16…З-29 проверены по содержанию и внесены (uuid-FK и типы возврата; контур break `planned_return`/`source auto|manual`/`break_update`; якорь Fenix 6X единообразно в vision/requirements/tech-req/architecture/readme/plan; ОВ-10 закрыт по О-1-А; `Safety.HrStrengthMax` в Ф-13.7 и обеих таблицах разд. 3; fetch 15 мин ↔ БЦ-5; migrate-режим и `src.migration`; перечень `LocalDb`; ui-ux 1.1; чек-лист ревью №1). Трассировка Ф → БЦ → КУ не нарушена; противоречий requirements ↔ vision по MVP-составу, правилам 1–17, ограничениям 45+/гипертония/мениск не найдено. Документация в целом соответствует исходной задаче, рекомендациям и ограничениям. С учётом уточнения владельца о программе тренировок найдено: **2 существенных дефекта (P1)** — Ф-13.7 называет программу тренировок нормативным источником и контур импорта пакета программы отсутствует в документации разработки; **1 средний (P2)** — рассинхрон шапок (architecture ↔ vision/requirements, снимается утверждением волны); **4 мелких (P3, гигиена)**, включая не соответствующий факту статус З-25 в чек-листе ревью №2. ## 1. Решения владельца (блокируют часть заданий) | Код | Вопрос | Варианты | Рекомендация ревью | |---|---|---|---| | **О-4** | Контур импорта пакета программы (`program-import.json`) в v1 не предусмотрен: `--mode import` принимает только .fit/.tcx/.gpx (Ф-8.3); формат пакета нигде не зафиксирован; `program_id` пакета — строка (`prg_2026_10_health_start`) против `src.program.id` serial; секция `profile.limitations` пакета не отражена в `program_version.body` | **А:** v1 без импорта пакета — программа заводится редактором телефона (Ф-4/Ф-5) и версионируется консолью владельца (Ф-10.2); в requirements (разд. 7) и tech-req явно записать «импорт пакета программы в v1 не предусмотрен — кандидат v2». **Б:** импорт пакета в v1 — расширение `--mode import` (формат `program-import.json`), маппинг на `src.program`/`src.program_version.body`; `program_id` строки — внешний идентификатор пакета (колонка `external_id UNIQUE`); `profile.limitations` — Safety-порогами НЕ управляет (только конфиг `Safety.*`), v1 секцию игнорирует | **Б** (следует из уточнения владельца: пакет — механизм эксплуатации; иначе путь доставки программы атлету в v1 не закрыт). Формат зафиксировать отдельным документом `3-tech\program-import-format.md` | ## 2. Задания P1 (существенные, блокируют шаг 7) ### З-30. Ф-13.7: программа тренировок — не нормативный источник ⬜ Противоречие: Ф-13.7 (`requirements.md`, раздел 5, Ф-13, п. 7) — «Источник — программа тренировок и документ метрик (п. 2.3)». По уточнению владельца программа — импортируемые данные атлета, нормативом для разработки быть не может; иначе порог пульса силовой части зависит от содержимого эксплуатационного пакета, а не от требований. 1. `1-docs\1-reqs\requirements.md`, Ф-13.7 — заменить последнюю фразу: «Источник — документ метрик (п. 2.3); значение перенесено в параметр конфигурации `Safety.HrStrengthMax` (разд. 3, умолчание 120). Программа тренировок — импортируемые данные атлета (см. О-4); нормативным источником требований не является». 2. `1-docs\0-mng\review-2026-10-17-2.md`, задание З-20 (и шапка, строка 11) — добавить примечание «уточнение владельца 2026-10-17 (ревью №3): `program-trenirovok.*` — импортируемый пакет эксплуатации; формулировка источника в Ф-13.7 скорректирована по З-30», чтобы формулировку не скопировали повторно. 3. Самопроверка: grep по `1-docs` — не осталось мест, где `program-trenirovok` или «программа тренировок» названа источником/нормативом требования (описание функциональности — «программы тренировок формируются/редактируются» — допустимо). ### З-31. Контур импорта пакета программы (после О-4) ⬜ Пакет программы — заявленный механизм эксплуатации, но путь его попадания в систему не документирован; формат не зафиксирован; схема БД не согласована с пакетом. По **О-4-Б** (рекомендовано): 1. `1-docs\3-tech\tech-requirements.md` — п. 2.1: сущность `program` дополнить `external_id` (строка, UNIQUE — идентификатор пакета); решение в разд. 1: «Импорт пакета программы — `--mode import`, формат `program-import.json` (см. `program-import-format.md`); повторный импорт пакета с тем же `external_id` — новая версия `program_version`». §5/§6 — при необходимости. 2. Новый документ `1-docs\3-tech\program-import-format.md` — формат пакета: структура недель → тренировок → упражнений → подходов; `program_id` (строка), `profile` (v1 игнорируется, поля задокументированы); коды возврата — как у import (requirements 2.3). 3. `1-docs\2-db\src\tables.md` — `src.program`: колонка `external_id | text UNIQUE NULL | идентификатор пакета (program-import.json)`; `program_version.body` — примечание: секция `profile` пакета в body не переносится (v1). 4. `1-docs\2-db\src\functions.md` — `program_insert`/`program_version_insert`: параметры/комментарии под `external_id` (список функций не меняется). 5. `1-docs\1-reqs\requirements.md` — Ф-8.3: источник импорта пополняется «пакет программы (`program-import.json`)»; раздел 7 — новый закрытый вопрос со ссылкой на tech-req. По **О-4-А**: только п. 5 в усечённом виде — «импорт пакета программы в v1 не предусмотрен (программа — редактор телефона/консоль владельца); кандидат v2» + закрытый вопрос в разд. 7; п. 1–4 не выполнять. 6. Трассировку раздела 6 не менять (Ф-8 уже привязан). ## 3. Задания P2 ### З-32. Рассинхрон шапок (снимается утверждением волны) ⬜ - `1-docs\2-arch\architecture.md`, шапка (стр. 4–8): «vision.md (v1.4, изменения 1.1–1.4)» → v1.5 (изменения 1.1–1.5); «requirements.md v1.4 (черновик, ревью №2)» → актуальная версия по факту утверждения пакета. - `1-docs\1-reqs\requirements.md`, шапка: «vision.md (утверждён 2026-10-17, v1.5)» — статус «утверждён» корректен только после утверждения vision 1.5 владельцем; привести к факту при утверждении. - Выполняется **в момент утверждения пакета** (одним диффом с проставлением статусов УТВЕРЖДЕНО в шапках vision 1.5, requirements, tech-req, architecture 1.2, tables/functions). ## 4. Задания P3 (гигиена) ### З-33. Байт backspace в `2-db\readme.md` + статус З-25 ⬜ 1. `1-docs\2-db\readme.md:47` — физический байт backspace (0x08): текст «2-db\uild.ps1» (визуально «2-dbuild.ps1») → заменить на корректный «2-db\build.ps1» (проверка: `od -c` не должен показывать `\b`). 2. `1-docs\0-mng\review-2026-10-17-2.md`, чек-лист, З-25 — статусная формулировка «опечатка в readme не подтвердилась — путь верен» **не соответствует факту**: исправить на «опечатка подтвердилась (байт 0x08), исправлена по З-33». ### З-34. Косметика tables/functions/ui-ux ⬜ 1. `1-docs\2-db\src\functions.md` (exercise_delete, стр. 30) и `src\tables.md` (комментарий `is_active`): «`is_active=0`» → «`is_active=false`» (колонка boolean). 2. `1-docs\2-db\src\functions.md` (workout_insert, стр. 42): комментарий «повтор `client_guid`» → «повтор `p_id` (uuid — PK клиентской сущности, генерирует телефон)» — терминология уровней sync/БД. 3. `1-docs\3-tech\ui-ux-recommendations.md`, §6.2 (стр. 76): остаток «ввод RPE/боли — задача часов» пометить как неприменимое к форме «поле данных» (так же, как на стр. 81: кнопки обрабатывает Garmin, Ф-2.5–2.6; ввод RPE/боли — телефон, Ф-13.3). ## 5. Порядок исполнения и версии **Один пакет:** З-30, З-32, З-33, З-34 сразу; З-31 после О-4 (по рекомендации — О-4-Б). Все правки — в текущие черновые версии волны ревью №2 (vision 1.5, requirements 1.4, tech-req 1.4, architecture 1.2, tables/functions новая редакция, 2-db readme новая редакция, новый `program-import-format.md`). При утверждении пакета — З-32 (шапки, статусы УТВЕРЖДЕНО) → одно утверждение владельцем → коммит и push (только `1-docs\` + корневой `readme.md`; `program-trenirovok.*` и `program-import.json` — отдельно по решению владельца) → **шаг 7**. ## 6. Чек-лист | Задание | P | Зависит от | Статус | |---|---|---|---| | О-4 решение владельца (импорт пакета программы) | — | — | ✅ О-4-Б (2026-10-17) | | З-30 Ф-13.7 источник (не программа) | 1 | — | ✅ (2026-10-17) | | З-31 контур импорта пакета программы | 1 | О-4 | ✅ (2026-10-17, по О-4-Б) | | З-32 шапки architecture/requirements | 2 | утверждение пакета | ✅ (2026-10-17, утверждено) | | З-33 backspace 2-db\readme.md + статус З-25 | 3 | — | ✅ (2026-10-17) | | З-34 косметика (is_active=false, p_id, ui-ux 6.2) | 3 | — | ✅ (2026-10-17) | | Коммит и push (только 1-docs + readme) | — | утверждение | ✅ (2026-10-17) | | Подтверждение владельцем правки program-trenirovok v4→v5 | — | — | ⬜ | ## 7. Самопроверка после правок 1. **requirements.md:** Ф-13.7 — источник «документ метрик + `Safety.HrStrengthMax`», программа названа импортируемыми данными; Ф-8.3 согласован с решением О-4; трассировка раздела 6 не изменена. 2. **Grep по `1-docs`:** нет упоминаний `program-trenirovok` / «программа тренировок» как источника требования; термин «пакет программы» (`program-import.json`) присутствует по О-4-Б (tech-req, requirements, tables/functions, format-документ). 3. **tables/functions:** `src.program.external_id` есть, функции согласованы, перечень таблиц ↔ функций 1:1 сохранён. 4. **2-db\readme.md:** `od -c` строки 47 без `\b`; путь «2-db\build.ps1» корректен. 5. **Шапки:** architecture ↔ vision v1.5 ↔ requirements ↔ tech-req — версии и статусы совпадают с фактом утверждения. 6. **Git:** в коммит вошли только `1-docs\` и корневой `readme.md`; push выполнен; `git status` по `1-docs\` чистый. ## 8. Отмечено при проверке (не задания) - Чек-лист ревью №2 («push выполнен после каждой волны») не соответствовал факту: правки волны в рабочей копии не закоммичены. Коммит/пуш выполняется по п. 5 настоящего файла — после утверждения. - Изменение корневых `program-trenirovok.md`/`.json` (v4→v5) и новый `program-import.json` — эксплуатационные данные, правилами ревью не регулируются; в документационный коммит не включать; авторство правки подтвердить у владельца.