card: kit-dev-flow прогон dwfrun-11c8179d — DevHub итерация «группы шаблонов + IsAuto + фильтр списков» (partial, 13 агентов, 21 эскалация)

This commit is contained in:
parent 88b568e1e7
commit 0802ceed54
1 changed files with 165 additions and 0 deletions

View File

@ -0,0 +1,165 @@
---
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» — скорость ответа владельца
определяет доезжание хвостов.