DB.FlowExp_WorkStatistics/runs/2026/2026-11-06-1-devhub-шаблоны...

166 lines
16 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.

---
date: 2026-11-06 10:28 # конец окна прогона (этапный коммит 3584c6d в 10:10, карточка 10:28); точное время пресетом не фиксируется
project: tasks/1-devhub/шаблоны-группы-isauto
step: tasks/1-devhub/шаблоны-группы-isauto
kind: этап-модуля
form: preset
preset: kit-dev-process
model: GLM-5.3-Flash
agents: 13
revisions: 0 # у пресета нет циклов ревизии
escalations: 21
result: partial
duration_min: "-" # пресетом не фиксируется
run_id: dwfrun-11c8179d-2b4a-4f42-9eca-597e7b82bfd6
---
## Что делали
Задача — итерация «группы шаблонов + флаг IsAuto + фильтр списков» в рамках
шага 7 «Итерационная разработка» проекта DevHub (std1/_process/process.md §7).
Бриф — tasks/1-devhub/шаблоны-группы-isauto/start.md; module_reqs.md в папке
нет (проверено ls 2026-11-06 10:28: в папке 6 файлов — start.md, тз-этапа.md,
рецепт_этапа.md, ревизия-этапа.md, отчёт_замыкания_итерации.md,
метрики-итерации.md), шаги 1–6 проекта закрыты (plan.md:10-16), поэтому sd-init
и d-drg к задаче не применимы — диаграмм в границах изменений нет. Размах:
TaskHub (миграция 020 БД, функции, репозиторий, контроллер, синк-сервис,
C#-тесты), DevHub (Flutter: модель, фильтр в двух списках, редактор, сиды,
Dart-тесты) и документы итерации.
План построен по конвейеру dx-flow: «ТЗ этапа → Реализация → Интегратор-гейт →
Ревизия свежим контекстом → Правки по находкам ревизии → Контрольный гейт →
Замыкание итерации: каскад, метрики, коммит» — с обязательными ролями
интегратора-гейта и ревизора свежим контекстом (прямое требование
start.md:132-138) и в режиме авточемода (plan.md:24-27, start.md:6-9): работа не
останавливается на развилках вне брифа — они фиксируются в approvals владельца с
honest-skip затронутой части. 13 агентов, 21 эскалация.
Итог partial: код и тесты этапа реализованы, точечные прогоны зелёные, этапный
коммит 3584c6d сделан 2026-11-06 10:10 (проверено git show --stat: 32 файла,
+2256/−54). Не закрыто прогоном: полный гейт (dotnet build Kit.TaskHub.slnx,
полный dotnet test, flutter) по B4 — зона интегратора, исполнителю запрещён;
раздел метрик сдан после этапного коммита (отклонение от буквы задания
задокументировано в §9 отчёта замыкания — проверка этой сессии: метрики-итерации.md
создан 10:11:40, через 90 секунд после коммита, и на момент карточки ещё не
закоммичен, git status «??»); psql-покрытие db-tst отсутствует (honest-skip);
ручная приёмка на живом стенде и решение о заведении db-tst — за владельцем.
Детали — в «Уроках».
## Уроки (что учесть в следующий раз)
### Неудачи и хвосты
- **Утверждение брифа о тестах репозитория не подтвердилось**: задание
утверждало «тесты репозитория — файл существует, проверено find», но
отдельного файла тестов SQL-репозитория в Hub.Tests нет (find 2026-11-06:
только PipelineTemplatesControllerTests.cs с FakeRepo на
IPipelineTemplateRepository). Шва подмены транспорта в SQL-реализации нет —
PgSql.cs:117-131 строит NpgsqlCommand по string connectionString, юнит-тест
репозитория без БД невозможен. Компенсации: сверка колонок
group/is_auto в Select/List с db/020 по CommandText (миграция прочитана
фактически), 4 контроллерных теста на новые поля через FakeRepo, интеграционный
тест интегратора ТЗ §2.6(д) на копии схемы. Учесть: при планировании тестов
перепроверять утверждения брифа о существовании файлов до записи их в план;
для репозиториев поверх Npgsql без шва закладывать интеграционный тест на
копию схемы, а не юнит.
- **Полный гейт не гонялся — и правильно**: dotnet build Kit.TaskHub.slnx /
полный dotnet test / flutter по B4 принадлежат интегратору, исполнителю
запрещены; точечные прогоны зелёные. Проекты вне Hub.Core/Hub/Hub.Tests
(Implementations, Runner) точечным прогоном не накрыты — до интегратора это
надо явно числить в отчёте, а не терять.
- **Этапный коммит выполнен ДО сдачи раздела метрик** (честно задокументировано
в §9 отчёта замыкания): стадии «ревизор-метрик» в плане этапа не было,
артефактов метрик на момент замыкания не существовало (grep «метрик» по папке
задачи и find -name '*метрик*' — пусто; ls tasks/1-devhub/1-docs/0-mng — файла
нет). Состав этапного коммита по заданию (результат+ТЗ+отчёты+рецепт) метрики
не включает, содержимое коммита от порядка не зависит; авточемод предписывает
не останавливать работу. Факт этой сессии: метрики-итерации.md создан 10:11:40
(после коммита 10:10) и ждёт отдельного документационного коммита после
независимого пересчёта. Учесть: если метрики обязательны — закладывать стадию
ревизора-метрика в план ДО этапа замыкания, иначе раздел метрик опаздывает
структурно, а не случайно.
- **Токены и wall-clock этапов/итерации недоступны из прогона**: платформа
workflow не отдаёт, в реестре этапов не фиксировались — в E2 записано честно
«не измерено» списком (dx-check E2); время в §1.1 отчёта — время
ТЕСТ-ПРОГОНОВ сессии замера, а не этапов, подменять им этапные метрики нельзя.
- **Независимая перепроверка ревизии сделана выборкой, не полным перебором**:
20 из ~40 якорей (все точны), полный список покрывает ревизия-этапа.md §4.
Приемлемая форма, но долю выборки и ссылку на полный список надо фиксировать
явно — чтобы выборочную перепроверку не читали как полный повтор гейта.
- **Метрика «доля документационных коммитов итерации» на момент замера
не существует** (коммита ещё не было): дан замер по истории ветки (51% вся,
80% последние 10), пересчёт после этапного коммита передан каскаду. Урок:
метрики, зависящие от итогового коммита, планировать после него с явной
передачей каскаду, а не «посчитать сейчас».
- **Собственный инструмент может врать**: первая версия python-парсера сидов
дала 2 ложных «✗» (в сверку попали имена файлов вместо имён шаблонов) —
ошибка инструмента, не данных; после исправления все 4 сверки чисты (§1.5).
Учесть: вердикт самодельного парсера перепроверять глазами на малой выборке
до записи результата.
- **Конфликт с пулом правил db-tst-3 (honest-skip отчёта §4.2)**: psql-тестов
на переписанные функции config.Pipeline_Template_Insert/Select/List нет —
каталога apps/TaskHub/db/tests не существует (ls: No such file or directory).
Покрытие — только C#-тесты контроллера на FakeRepo + функциональные пробы по
рецепту. Отступление от «каждая функция покрывается тестами: основной +
граничные» остаётся открытым хвостом (пересекается с В-4) до решения
владельца о заведении db-tst.
- **Конфликт с пулом правил d-tst-10 (находка В-4)**: PipelineTemplateRepository
(Sql/) без unit-теста транспорта — шва подмены в PgSql (строка подключения,
NpgsqlCommand) нет; компенсации (сверка CommandText↔db/020, контроллерные
тесты) проверены. Закрытие — тот же шов, что и в первом пункте: либо шов
подмены в PgSql, либо интеграционный тест на копию схемы как норма для
SQL-репозиториев.
- **Расхождение семантики фейка и прод-кода (наблюдение ревизии, в реализацию
не вмешивались)**: FakeRepo (PipelineTemplatesControllerTests.cs:36-50) на
ветви «существующая строка» возвращает сохранённые Group/IsAuto строки, а
SQL-реализация (PipelineTemplateRepository.cs:43-47) — переданные значения
(функция Insert возвращает только created/id/name); ветвь тестом не покрыта.
Контракт интерфейса (IPipelineTemplateRepository.cs:42-46) отсылает за
фактическими значениями к Select/SelectAll — дефектом по контракту не
является, но есть кандидаты: ветвь-тест либо выравнивание фейка. Учесть:
при добавлении новых полей сверять семантику фейка с SQL-реализацией, а не
только с интерфейсом.
- **Escalations: 21 при 13 агентах** — заметная часть решений ушла в approvals
владельца; разбивка по темам каждой эскалации в материал прогона не попадает
(тот же слепой слот, что в карточке dwfrun-10fa0e8f с 10 эскалациями при
4 агентах) — формату отчёта рана нужен состав эскалаций, иначе петля
«неудачные приёмы исключаются» работает вслепую.
### Лимиты и условия
- **Правил Dart/Flutter в корпусе нет**: реестр std1/_rules/readme.md §4.2
покрывает только C#/SQL/d-области (d-fe и прочие ⬜ «по мере появления» —
readme.md:71-73,103). Flutter-зона велась по карте кода и проектным решениям
start.md и паттернам существующего кода DevHub; машинная проверка — только
flutter analyze / flutter test. До появления правила зона будет повторяться
в каждом Flutter-этапе.
- **psql-тесты db-tst в apps/TaskHub/db не заведены** (ls: только миграции
001–019, папки tests/ нет), и прогон PL/pgSQL-тестов не входит в гейты
итерации (start.md:122-127). Обновлённые функции 020 проверяются опосредованно
— C#-тестами и подъёмом миграции на тестовой БД; полноценное покрытие db-tst —
отдельное решение владельца, прогон его выполнить не сможет.
- **Именование функций TaskHub (Pipeline_Template_Insert, PascalCase)
расходится с нормой readme.md §6 ({слой}.{сущность}_{действие})**: итерация
сохраняет существующие имена через CREATE OR REPLACE по брифу
(start.md:89-93) — переименование вне границ итерации.
- **Передача isAuto=true из потока создания задачи из СУЗ вне границ
итерации**: карта кода start.md:48-52 фиксирует, что автозаписей шаблонов при
создании задачи нет и появиться не должно (SupertaskController/
SupertaskExpander не трогаются) — параметр апсёрта существует с default false;
правка потока СУЗ — будущая отдельная задача.
- **Живая приёмка и рестарт контейнеров — только владелец** (start.md:9,
129-130): ручной проход UI на стенде и рестарт недоступны прогону; его
пределы — гейты build/test/analyze и подъём миграции на тестовой БД.
- **Критерий отбора is_auto=true «API-шаблоны (id 5–8 на стенде)» проверяется
по данным живой БД стенда, недоступной из прогона**: ревизия проверяет код
миграции (критерий по данным с комментарием), но не сами данные стенда.
- **Метрики токенов/wall-clock (Б3, E2)** — только если платформа workflow
отдаёт числа; иначе честное «не измерено», не синтетика.
- **Файла ретроспективы проекта DevHub нет** (ls tasks/1-devhub/1-docs/0-mng/):
приписка E4 кладётся в отчёт замыкания итерации, а не в отдельный файл;
создание постоянного файла ретроспективы — решение владельца.
- **Развилка вне брифа требует эскалации владельцу**: в режиме авточемода
прогон сам её закрыть не может — либо ждёт ответ, либо фиксирует развилку в
approvals с honest-skip затронутой части. При 21 эскалации это основной
механизм превращения «partial» в «success» — скорость ответа владельца
определяет доезжание хвостов.