# Рекомендации еженедельного анализа kit-dev-flow — 2026-11-05 Исполнитель: этап «analyst» конвейера (авто). Источники: `_summary.md` (flow_stats.py от 2026-11-05), `baseline/2026-11-05-до-петли.md` (93 до-петлевых прогона в 3 проектах, 23.10–04.11), `dx-flow.md` (эталон: 14 метрик А1–Г3, цели/триггеры, светофор от 2026-11-02). Карточек в `runs/` нет — по инструкции анализ по до-петлевым свидетельствам baseline. ## Состояние на дату - **Прогонов через петлю: 0.** `flow_stats.py` отработал без ошибок (EXIT=0) по трём выборкам: все проекты (`--write-summary`), `--kind этап-модуля`, `--kind документ` — везде «Карточек: 0 (проектов: 0)», средние «—». - До-петлевая фактура (baseline §2): 93 workflow-прогона (Kit.RAG 84, Kit.DevAi 7, Kit.ZСode.Plagins 2 + 3 dwfeval-прогона), все **generated** — пресетных 0; 6 амдментов/resume из 93 (6,5 %). - Новых замеров А1–Г3 нет: светофор остаётся от 2026-11-02 (А1–А4, Б1, Б2, В2, В4 — 🟡; Б3, В1, В3, Г1–Г3 — 🟢). ## Сверка с целями dx-flow (метрики хуже цели — кандидаты в рекомендации) | Метрика | Цель | Последний факт | Светофор | Триггер dx-flow | |---|---|---|---|---| | А1 находки ревизии, high | high=0 | медиана 2/этап (И3–И6, цель ≤2 достигнута), но И3-э1: **2 high** | 🟡 | high на этапе → усилить B-блок ТЗ и фокус ревизии | | А2 псевдо-якоря | 0 | И3-э1: **2** | 🟡 | >0 → приём в dx-flow + формулировка dx-dev-8 | | А3 дефекты после замыкания | 0 | И1: этап «доезжал» **×2** (новее нет) | 🟡 | >0 → ужесточить замыкание (контрольный + хвосты) | | А4 повторы известных граблей | 0 | И2: **3** (кодировка/лок/байты); И3: инструменты введены, повторов не зафиксировано | 🟡 | 1-й повтор → инструмент; 2-й → эскалация владельцу | | Б1 доля док-коммитов | ≤40 % | И1 ~70 %, И2 ~56 % — **две итерации подряд >50 %** | 🟡 | >50 % две итерации → упрощать каскад (одно место статусов) | | Б2 redo-прогоны/этап | ≤1 | И1 4, И2 2 (**хуже цели**); И3/И4 0 — тренд закрыл цель, данных петли нет | 🟡 | >2 → стабильность скриптов (маркер «ТЗ vN») | | В2 темы с первого захода | ≥75 % | 2/4 = **50 %** | 🟡 | <75 % → тюнинг запросов / ускорить `--tag env:*` | | В4 возраст docChanges | ≤1 итерации | до **4 этапов** | 🟡 | >1 итерации → выносить легализацию чаще | Правило светофора соблюдено: каждая строка выше — кандидат; ниже — TOP по стоимости/срочности. Метрики в цели (Б3 ×3–5, В1 16/16, В3, Г1–Г3) в рекомендации не входят. ## TOP-рекомендации ### R1. Замкнуть петлю: запись карточки не должна держаться на памяти агента **Тип:** семантическая · **Приоритет:** 1 (блокирует все остальные). - **Доказательство:** карточек 0 при трёх запусках flow_stats.py; baseline §1 — петле 4 часа, §5.2 возлагает запись карточки на агента сессии («молча, сразу») — механизм ничем не проверяется; baseline §2.5 — авто-записи карточки нет ни в пресетах, ни в одном из 93 скриптов (grep «карточк|flow_exp|FlowExp» — 0 совпадений). Преедент механики есть: плагин sys-qa-interactive использует хук PostToolUse (hooks.json, timeoutMs 15000) — baseline §4. - **Действие:** закрепить запись карточки механизмом, а не инструкцией: хук плагина kit-knowledge (по прецеденту sys-qa-interactive) или обязательная финальная стадия workflow/пресета («карточка + commit»). - **Как проверить:** после следующего workflow-прогона в `runs/` появляется карточка и `flow_stats.py` показывает «Карточек: ≥1». Контрольный срок — 2 недели: снова 0 ⇒ механизм мёртв, эскалация владельцу навыка. ### R2. Канонизировать словарь kind (иначе фильтры теряют карточки) **Тип:** механическая · **Приоритет:** 2. - **Доказательство:** README журнала — пример `kind: db` и словарь «документ | требования | архитектура | db | этап-модуля»; SKILL.md (строка 127 по baseline §1) — «БД»: расхождение регистра/языка в двух документах плагина. Фильтр `--kind` требует ТОЧНОГО совпадения (flow_stats.py:93 `meta.get("kind") != kind`) ⇒ «БД» и «db» станут двумя разными классами, выборки будут терять карточки. - **Действие:** зафиксировать в README единственный канонический словарь из 5 значений (латинское `db`), синхронизировать SKILL.md; в flow_stats.py — нормализация kind (trim/lower + синонимы «бд→db») до сравнения. - **Как проверить:** тестовая карточка с `kind: БД` попадает в выборку `--kind db`; в отчёте по kind класс один, а не два; в README и SKILL.md словари совпадают дословно. ### R3. Согласовать поля карточки с метриками А–Г (главное — findings и tokens) **Тип:** механическая (имена полей карточки) · **Приоритет:** 3. - **Доказательство:** baseline §5: поле `revisions` численно не определено (коллизия А1 «находки ревизии» vs Б2 «redo-прогоны»); нет поля для А1 — единственной метрики с готовой базой (53→2), хотя findings[] есть в отчёте каждого рана; `duration_min` покрывает только половину Б3 — токенов в карточке нет; парсер распознаёт только белые списки STR_FIELDS/NUM_FIELDS (flow_stats.py:23–25) — новые поля молча теряются. - **Действие:** расширить шапку карточки полями `findings` (всего находок ревизии), `findings_high`, `redo` (амдменты/resume), `tokens`; определить `revisions` = «циклы правок по находкам ревизии» (Б2 — отдельное поле); добавить новые поля в NUM_FIELDS парсера одним коммитом с README. - **Как проверить:** карточка-фикстура с новыми полями не теряет их при прогоне flow_stats.py; в `_summary.md` по kind=этап-модуля появляется среднее по findings — прямая сверка с целью А1 без ручного сбора. ### R4. Доработать каркас пресетов до модального паттерна или снять приоритет **Тип:** семантическая · **Приоритет:** 4. - **Доказательство:** 0 пресетных прогонов из 93 (grep маркеров пресета по payload — 0 совпадений, baseline §2.2); в пресетах нет независимого ревизора и интегратора как роли, только dotnet build/test (§2.5); сгенерированный модальный паттерн Kit.RAG (3 агента/5 ask: зоны → интегратор-гейт → ревизор свежим контекстом → контрольный гейт, §2.3) совпадает с эталоном dx-flow «факт-в-факт» (§4) — пресеты от эталона отстают. - **Действие:** привести `kit-dev-process.dwf.ts`/`kit-dev-tdd.dwf.ts` к модальному паттерну (исполнители по зонам с мандатами, интегратор-гейт, ревизор свежим контекстом, контрольный гейт) и встроить запись карточки (см. R1); до выравнивания не форсировать приоритет пресетов из §3.2 SKILL.md. - **Как проверить:** текст пресета содержит роли интегратора и ревизора (grep); первый пресетный прогон даёт карточку с `form: preset`; в `_summary.md` таблица «форма» наполняется обеими ветками (preset ≥1, generated ≥1) — сравнение форм становится числовым. ### R5. Исполнить сработавшие триггеры Б1 и В4 (действия в проектах, через ретроспективу) **Тип:** семантическая · **Приоритет:** 5. - **Доказательство:** Б1 — И1 ~70 %, И2 ~56 %: две итерации подряд >50 % при цели ≤40 % ⇒ триггер «упрощать каскад» УЖЕ сработал; приём «дублирование статусов в 3+ документах — НЕ окупилось» в dx-flow есть, метрика всё равно 🟡 — по правилу карточки: правило соблюдается, а метрика хуже цели ⇒ на следующей ретроспективе пересмотреть оценку/соблюдение. В4 — возраст docChanges до 4 этапов при цели ≤1 итерации ⇒ триггер «выносить легализацию чаще». - **Действие:** в ближайшей ретроспективе проекта (правки знаний — только через неё): каскад статусов — строго одно место (readme модуля) + ссылки; легализацию docChanges — на каждом замыкании этапа. - **Как проверить:** замер git log проекта следующей итерации — доля док-коммитов ≤50 % (цель ≤40 % к следующей); возраст старейшей записи docChanges на легализации ≤1 итерации. Замеры фиксируются строкой «итерация | метрика | значение | светофор | триггер | действие». ### R6. Исполнить триггер А2: приём против псевдо-якорей в dx-flow + dx-dev-8 **Тип:** семантическая · **Приоритет:** 6. - **Доказательство:** А2 = 2 (И3-э1) при цели 0, светофор 🟡; триггер метрики требует «приём в dx-flow + формулировка dx-dev-8», но отдельного приёма в таблице приёмов dx-flow нет — псевдо-якоря упомянуты только косвенно (комментарий к «Ревизии свежим контекстом»). - **Действие:** ретроспективой (владелец в контуре утверждения) дописать в dx-flow приём «якоря перепроверяются живым запросом (dx-dev-8), числа пересчитываются парсером» с числом-прецедентом; проверить, что формулировка dx-dev-8 содержит требование живой перепроверки. - **Как проверить:** в dx-flow появился приём с прецедентом-числом и строкой замера; на следующем этапе с ревизией А2 = 0 (замер из findings карточки по R3). ### R7. Механические дефекты журнала: ссылка, пустая таблица, «#» в значениях **Тип:** механическая · **Приоритет:** 7. - **Доказательство:** dx-flow.md:8 — ссылка `[readme.md](../../readme.md)` из корня журнала ведёт вне репозитория (битая в этом клоне: файл лежит в std1-ext проекта Kit.DevAi); flow_stats.py render() при 0 карточек печатает пустую таблицу «| форма | прогонов | success |» без строк (наблюдено в текущем `_summary.md`); парсер режет «#» внутри значения (flow_stats.py:60 `val.split(" #")[0]`) — значение с решёткой потеряет хвост. - **Действие:** заменить ссылку на явный источник («эталон: Kit.DevAi/std1-ext/_rules/dx/dx-flow.md»); не печатать таблицу без строк; в README (формат карточки) — запрет `#` в значениях шапки. - **Как проверить:** из журнала ссылка ведёт в осмысленное место либо заменена текстовым указанием пути; `_summary.md` при 0 карточек без пустой таблицы; карточка со значением без «#» читается парсером целиком. ## Не вошло в TOP (осознанно) - **В2 темы с первого захода 50 % < 75 %** — контур RAG-корпуса, не петля; триггер (тюнинг запросов, `--tag env:*`) уже в «Открытых хвостах» dx-flow. - **А3, А4, Б2** — последние факты (И1/И2) хуже цели, но есть свежие свидетельства исправления (И3–И7: замыкание с контрольным гейтом, инструменты среды, redo 0); пересчёт возможен только по карточкам петли (R1/R3), до того — ждать данных. - **Г1–Г3, В1, В3, Б3** — в цели, светофор 🟢, действий не требуют. ## Что сделано этим прогоном аналитика - Запущен `flow_stats.py` трижды (все проекты + `--write-summary`; kind «этап-модуля»; kind «документ») — везде 0 карточек; `_summary.md` обновлён скриптом. - Прочитаны README.md, dx-flow.md, baseline (карточек в runs/ нет — работа по baseline, как предписывает инструкция). - Записаны: этот файл и `_recommendations.md` (перезаписан). Карточки runs/ и остальные файлы журнала не тронуты. Коммит не выполнялся (отдельный этап конвейера).