DB.FlowExp_WorkStatistics/llm-artifacts/02-analysis.md

Рекомендации еженедельного анализа 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.

Артефакты, записанные в журнал: recommendations/2026-11-05-рекомендации.md (этот документ), _recommendations.md (перезаписан, TOP-таблица), _summary.md (обновлён скриптом). Коммит не выполнялся — отдельный этап конвейера.

Состояние на дату

• Прогонов через петлю: 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/2026-11-05-рекомендации.md и _recommendations.md (перезаписан). Карточки runs/ и остальные файлы журнала не тронуты. Коммит не выполнялся (отдельный этап конвейера).