VEU
/
VEU.WathBody
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
VEU.WathBody/1-docs/0-mng/agent-recommendations-2026-...

14 KiB
Raw Blame History

Рекомендации агенту — этап 7, волна 2 (итоги ревью 2026-10-18)

Получатель: кодирующий агент, выполняющий этап 7 «Итерационная разработка» (текущий модуль — m05-progression-rules, реализация завершена, шлюз 3.4 — у владельца; далее m06+ по plan.md). Источник: повторная архитектурная сверка артифактов этапа 7 с документацией (requirements 1.4, architecture 1.2, tech-requirements 1.4, 2-db, module_reqs/api_specs m01–m05), 2026-10-18. Дополнение к волне 1 — agent-recommendations-2026-10-18.md (З-35…З-40). Базовые файлы стандарта std1\ и библиотека Kit.Helpers не править — все исправления только в проектных файлах этого репозитория. Статусная модель заданий: ⬜ не начато → 🔄 в работе → ✅ готово (утверждено владельцем). Нумерация З-41+ продолжает З-40.

0. Итог сверки (что подтверждено — не перепроверять)

  • Волна 1 исполнена и подтверждена: З-35 — полностью (миграция 003, program_insert rev. 2 с DROP прежней сигнатуры, spec, домен Program.ExternalId + ProgramRepository.Insert, psql-кейс UNIQUE + Core-тест Insert_2СExternalId, errata в readme m01 и plan.md); З-40 — все 4 пункта; З-37 п. 4 — диапазоны 1–20 / 3–12 в коде; З-38 — статусы m05 выставлены корректно (1.3/2.4/3 ✅, 3.4/4 ⬜ — у владельца).
  • Сборка решения — 0 ошибок / 0 предупреждений; прогон 2026-10-18 на docker watchbody-pg: Core.Tests 56/56, Web.Tests 80/80 (Integration 13 + Unit 12 + ProgramStore 19 + MetricsEngine 17 + ProgressionRules 19).
  • 38 psql-функций ↔ 38 спецификаций ↔ 38 psql-тестов; 13 репозиториев в 8 файлах; все функции потребляются, параметры передаются поимённо и совпадают с сигнатурами.
  • Инварианты волны 1 подтверждены повторно: изоляция p_athlete_id, идемпотентность по p_id, переходы draft → active → archived, атомарность пакета, ProgramStore — 7 методов, author=llm отклоняется, /api/admin/* отсутствует (m08 не начат), ключи — SHA-256 hex lowercase.
  • Правила m05: приоритет 1–5, делоад ×0.6/−1 подход, таблица возврата 1.0/0.9/0.85/0.75/ReturnMinFactor, правило 17 → test, дедупликация rules-черновиков, фильтр ограничений — соответствуют module_reqs m05.
  • Умолчания MetricsConfig/ProgressionConfig ↔ appsettings.json (Web и Web.Tests) совпадают полностью; мёртвых ключей RestingHrSitting/HrStrengthMax/LightWeekHrRise в серверных конфигах нет (Р3-А соблюдён).

1. Задание P1

З-41. Замкнуть контур is_active в sync (Ф-4.2) ⬜ (решение владельца)

Контракт передаёт is_active у exercise (tech-requirements 2.2, m02 module_reqs.md:79), SyncService.cs:184 значение парсит — и теряет: src.exercise_insert/exercise_update параметр p_is_active не принимают (дизайн m01 — флаг меняет только src.exercise_delete, З-34), а ExerciseRepository.Delete из sync не вызывается ни при каком входе. Итог: в v1 не существует ни одного рабочего пути установить is_active=false на сервере, при этом m05 строит на флаге фильтр ограничений (исключённые упражнения, api_specs\02-micro-adjust.md).

  • Рекомендация (а): в SyncService (case exercise) при is_active=false вызывать exercises.Delete(athleteId, item.ClientGuid) (→ src.exercise_delete; идемпотентно: 0 строк — не ошибка), при true/NULL — обычный Insert. GUID включать в accepted в обоих случаях (Ф-7.4). Единственный вариант, закрывающий серверный контур Ф-4.2 в v1. Правки: SyncService.cs; Integration-тест в Web.Tests (упражнение is_active=true → повтор пакета с is_active=false → в БД false, оба ответа accepted); m02 module_reqs + api_specs 06 — семантика «повторная отправка упражнения с is_active=false — логическое удаление»; tech-req 2.2 — примечание; errata в readme m02 (правка закрытого модуля — практика m01/m04); readme m05 п. 1 — дополнить. БД не меняется — прогон psql не требуется.
  • Альтернатива (б): убрать is_active из контракта (m02 module_reqs:79, tech-req 2.2), SyncService перестаёт парсить поле. Не рекомендуется: серверный контур Ф-4.2 в v1 не закрывается — ограничения атлета (исключения для правил) недостижимы до m08.

2. Задания P2

З-42. Документационная синхронизация код ↔ спецификации ⬜ (сразу агентом, без шлюза)

  1. m02 api_specs\06-dto.md — классы SyncRequest и RecordData* (стр. «Модели») не существуют: корень запроса — сырой JSON-массив, разбор data — SyncItemParser/JsonElement. Привести раздел к фактической реализации (поведение то же — описаны только имена моделей).
  2. Имя SQL-компонента Kit: kit-helpers-spec.md (таблица), tech-req разд. 3, 2-db\readme.md («Общие сведения») — заменить Db.Postgres.SqlServerHelper на фактический Kit.Helpers.SqlHelperAbstract (SqlHelperPostgres/ SqlHelperFluent — весь DAL и тесты). JsonHelper пометить «в v1 не потребляется» (ProgramStore/MetricsEngine — System.Text.Json напрямую); Log.Logger уже помечен (З-40.3). Строку «Сборка» (build.ps1 / Server.WatchBody.Import) в 2-db\readme.md не трогать — закрывается З-36 волны 1.
  3. m05 api_specs\05-sync-wiring.md — конструкторы по факту: ProgressionRules(IWorkoutRepository, IExerciseRepository, ProgramStore, ProgressionConfig) и BreakEngine(IWorkoutRepository, IBreakRepository, ProgramStore, ProgressionConfig); сниппет CheckDeload(athleteId) → CheckDeload(athleteId, today) (согласовать со spec 03 и SyncService).
  4. m05 api_specs\01 — диапазоны валидации синхронизировать с кодом (след З-37 п. 4): backoffPercent 1–20 (не «(0; 50]»), deloadMaxWeeks 3–12 (не «<1»).
  5. m05 api_specs\03 + readme m05 (примечания) — зафиксировать опорную точку делаода в v1: только факт-тренировка с session_kind=deload, иначе CreatedAt активной версии; вариант «rules-draft с deload в week 1» не реализован (кандидат — m08). Включить в дифф владельцу.
  6. m04 api_specs\02/03 — примечания (поведение осознанное, тесты зелёные): окно выборки daily_log расширяется на lightDayCount (поиск старта серии, MetricsEngine.cs:42); серия в ConditionRun ограничена lightDayCount (на флаги 2/3 не влияет); knee_pain_repeat — предыдущие тренировки строго до дня текущей (DateTo = дата − 1).
  7. Числа тестов: readme m05 — «Core 55/55» → 56/56 (plan.md:42 уже 56; правило «readme и plan той же правкой»); в readme m02/m03/m04 к «Core 55» добавить «(на момент закрытия модуля; после З-35 — 56)».
  8. Код, без шлюза (как З-37 п. 4): ApiKeyMiddleware — путь /health пропускать только для GET (сейчас — любой метод; деградирует в 404/405, не эксплойт). Проверить Unit-тесты middleware; прогон Web.Tests после правки.

3. Открытые шлюзы волны 1 (не дублируются, остаются в силе)

  • З-36 (--mode migrate: реализовать либо оформить перенос) — подтверждено: не исполнен ни в одном варианте; Program.cs не разбирает --mode/--config, ключа Db.MigrationsDir нет, 2-db\readme.md:47–48 ссылается на несуществующие build.ps1 и Server.WatchBody.Import. Пользователь!
  • З-37 пп. 1–3, 5 (правки tech-req 4.2: BpElevated* с Dias 95, фактические параметры сервера — hrRestingDays…returnMaxFactor, пометка «RestingHrSitting/HrStrengthMax/LightWeekHrRise — потребление телефон (m09), сервер в v1 не читает», camelCase) — код и конфиги уже согласованы, документ нет. Пользователь!
  • З-39 (примечание в requirements Ф-14.2/Ф-14.3: в v1 любой kind=illness трактуется как перезапуск — spec 04 m05) — Пользователь!
  • З-38 — порядок закрытия m05 без изменений: владелец утверждает 3.4 → агент закрывает шаг 4 и plan.md m05 ✅.

4. Порядок исполнения

  1. Сразу агентом: З-42 (пп. 1–4, 6–8); к пакету владельцу приложить проект решения З-41 (оба варианта с последствиями).
  2. Пакет на утверждение владельцу (один дифф): З-41 (выбор варианта), З-42 п. 5 (примечание spec 03 m05), плюс открытые шлюзы волны 1 — З-36 (выбранный вариант), З-37 пп. 1–3/5, З-39.
  3. После утверждения: реализация выбранного варианта З-41 (код + тесты + документы + errata m02); актуализация чисел тестов в readme m02 и plan.md той же правкой.
  4. Далее: шлюз m05 3.4 → шаг 4 (закрытие модуля) → plan.md m05 ✅; затем m06 по плану. Коммит и push волны — после утверждения; эксплуатационные файлы (program-trenirovok.*, program-import.json, presentation-trenirovok.html, Журнал_метрики.md) в коммит не включать.

5. Чек-лист

Задание P Шлюз Статус
З-41 контур is_active в sync — выбор варианта 1 Пользователь! ✅ (вариант а)
З-41 реализация выбранного варианта (+ тесты, errata m02) 1 — ✅
З-42 пп. 1–4, 6–8 (документация + middleware GET) 2 — ✅
З-42 п. 5 (примечание spec 03 m05) 2 в диффе волны ✅
З-36 / З-37 пп. 1–3, 5 / З-39 (волна 1) 2–3 Пользователь! ✅
З-38: гейт m05 3.4 → шаг 4 → plan.md m05 ✅ 2 Пользователь! ✅ (m05 закрыт)
Коммит и push волны — утверждение ⬜ (у владельца)

6. Самопроверка после исполнения

  1. Вариант З-41(а): повтор sync-пакета с is_active=false дважды — оба ответа accepted, в БД is_active=false; Web.Tests зелёные, новые числа — в readme m02 и plan.md.
  2. grep SyncRequest|RecordData по 1-docs\4-modules\m02-rest-api — 0 вхождений (или с пометкой «не реализовано»).
  3. grep Db.Postgres.SqlServerHelper по 1-docs — 0 вхождений; SqlHelperAbstract — в kit-helpers-spec, tech-req разд. 3, 2-db\readme.md.
  4. readme m05 — «Core 56/56»; числа согласованы с plan.md.
  5. dotnet build — 0 ошибок / 0 предупреждений; Core.Tests 56/56, Web.Tests 80/80 (docker watchbody-pg, порт 5433, БД watchbody).