VEU
/
VEU.WathBody
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
VEU.WathBody/1-docs/0-mng/review-2026-10-17-3.md

19 KiB
Raw Permalink Blame History

Ревью документации №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<BS>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 — эксплуатационные данные, правилами ревью не регулируются; в документационный коммит не включать; авторство правки подтвердить у владельца.