VEU.WathBody/1-docs/0-mng/review-2026-10-17-3.md

225 lines
19 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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