DB.FlowExp_WorkStatistics/runs/2026/2026-11-06-1-devhub-шаблоны-группы-isauto-11c8179d.md

date	project	step	kind	form	preset	model	agents	revisions	escalations	result	duration_min	run_id
2026-11-06 10:28	tasks/1-devhub/шаблоны-группы-isauto	tasks/1-devhub/шаблоны-группы-isauto	этап-модуля	preset	kit-dev-process	GLM-5.3-Flash	13	0	21	partial	-	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» — скорость ответа владельца определяет доезжание хвостов.