DB
/
DB.FlowExp_WorkStatistics
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
DB.FlowExp_WorkStatistics/baseline/2026-11-05-до-петли.md

26 KiB
Raw Blame History

Отчёт: статистика выполнения kit-dev-flow и до-петлевые свидетельства

Дата: 2026-11-05 · Исполнитель: агент (задача из ТЗ_анализ_статистики.md) Формат: каждый пункт — ФАКТ (число/файл-источник) или явно помеченная ИНТЕРПРЕТАЦИЯ. Коммитов нет, исходные файлы не правились.

1. Состояние петли опыта (§5 SKILL.md)

Факт Значение Источник
Карточек runs/**/*.md в журнале 0 I:\Kit\DB.FlowExp_WorkStatistics (find по runs/ — пусто; в корне только README.md и .git)
Коммитов в клоне журнала 1 (README, 14:03 05.11) git -C I:\Kit\DB.FlowExp_WorkStatistics log → 0683962 README: формат карточек…
Конфиг точки опыта настроен: flow_exp_dir + flow_exp_remote в ~/.zcode/kit-knowledge.json файл существует, оба поля заполнены
Remote клона валиден (DB/DB.FlowExp_WorkStatistics, creds в URL) git remote -v
Время создания петли README 14:03, §5 SKILL.md 14:06, flow_stats.py 14:08 (05.11) forensic-факты ТЗ (координатор)
flow_stats.py --kind этап-модуля EXIT=0, без ошибок; вывод: «Карточек: 0 (проектов: 0)», все средние «—», таблица форм пустая, «(нет провальных карточек в выборке)» запуск 05.11 из kit-knowledge/scripts/

Почему пусто (ИСТОЛКОВАНИЕ, согласуется с forensic): петле 4 часа; за это время не было ни одного workflow-прогона, запущенного через протокол §5 (последние прогоны — 01.11 в Kit.ZСode.Plagins и 04.11 в Kit.RAG, все до создания петли). Дополнительно: §5.2 возлагает запись карточки на агента сессии («молча, сразу») — механизм, который не проверяется ничем (см. предложения, п.1).

Парсер flow_stats.py (факт по коду, scripts/flow_stats.py):

  • YAML-шапка парсится упрощённо: строки ключ: значение между двумя ---; распознаются только поля из белых списков STR_FIELDS/NUM_FIELDS (строки 24–25); кавычки срезаются; значения с # обрезаются как комментарий (строка 60) — факт: значение вроде run_id: dwfrun-... пройдёт, но step: 7.4 этап 2 содержит пробелы — ок, а вот # внутри значения потеряет хвост.
  • Секция «Уроки» собирается только как строки - … после заголовка ## Уроки (строки 65–76) — варианты заголовка («## Уроки (что учесть…)») тоже матчатся (startswith), это ок.
  • Без карточек скрипт не падает: render() корректно выводит нули, деления на ноль нет (group_stats → ok*100//total достижим только при total>0). Агрегация при первой сотне карточек поведенчески не проверена (данных нет — дыра данных).
  • Фильтр --kind требует ТОЧНОГО совпадения строки kind: значения из аннотации §5.2 («документ|требования|архитектура|БД|этап-модуля») vs README-пример (kind: db) уже расходятся в регистре/языке («БД» vs «db») — факт-несоответствие двух документов плагина (skills/kit-dev-flow/SKILL.md строка 127 vs DB.FlowExp_WorkStatistics/README.md пример карточки).

2. Реальные workflow-прогоны на диске (до-петлевая фактура)

2.1. Сводка по проектам

Проект dwfrun dwfeval Период (mtimes) Амдментов (resumedFrom) Источник
Kit.ZСode.Plagins 2 1 01.11 12:24–13:42 1 .zcode\workflow-runs\ (3 файла, ls)
Kit.DevAi 7 0 23.10 16:46–24.10 08:37 0 .zcode\workflow-runs\
Kit.RAG 84 2 30.10 18:11–04.11 19:43 5 (по метаданным payload; ретроспектива называет «6 resume/amend» на 39 прогонов к 01.11) .zcode\workflow-runs\, метаданные run в payload
Итого найдено 93 3 23.10–04.11 6 подсчёт по ls + payload

Драфты: Kit.ZСode.Plagins — 1 (Сборка-плагина-file-editor.dwf.ts, 47 КБ), Kit.DevAi — 5, Kit.RAG — 28. Планы (.zcode\plans): 2 в Kit.ZСode.Plagins (01.11 сборка file-editor; 05.11 план создания самого kit-dev-flow — факт: пресеты задуманы как «уже есть в ~/.zcode/workflows», строка 7 плана).

2.2. Форма прогонов: preset | generated

  • ФАКТ: пресеты kit-dev-process.dwf.ts (14 194 Б, 27.10 16:43) и kit-dev-tdd.dwf.ts (15 337 Б, 27.10 17:14) существуют в C:\Users\virus-home\.zcode\workflows\.
  • ФАКТ: ни один из 93 .mjs на диске не содержит маркеров пресета («Архитектор формирует процесс задачи», «Страховочная проверка», «Гейт сборки и контроль дисциплины», «rulesPath») — grep по распакованным payload всех прогонов дал 0 совпадений (в 57 прогонах есть строка «dotnet build» — это гейты C#-проектов Kit.RAG/Kit.DevAi, не пресет).
  • ВЫВОД (интерпретация, высокая уверенность): 100 % найденных прогонов — generated; пресеты после создания 27.10 ни разу не запускались (или прогон не оставил следа — для saved-запусков .mjs в workflow-runs пишутся так же, след бы был). Статистика «preset vs generated» из карточек не накоплена — форма во всех фактических прогонах = generated.

2.3. Топологии (числа по распакованным payload lowered-скриптов)

Kit.RAG (84 dwfrun): модальный паттерн этапа модуля — 3 агента / 5 ask / 4 фазы / 4 report (38 из 84 файлов — точно эта форма; ещё ~10 — вариации 3–4 агентов). Проверенный образец: dwfrun-f63a6556 (этап 1 модуля serve) =

  1. Исполнитель Api-DTO (зона + общий МАНДАТ-блок COMMON: «правишь ТОЛЬКО …; ЗАПРЕЩЕНО: 1-docs, 2-db…»)
  2. Интегратор: dotnet build + KITRAG_PG_TEST=1 dotnet test (гейт выполняется агентом с Bash, НЕ world.run)
  3. Независимый ревизор (severity low/medium/high, сверка с каноном, файлы не правит)
  4. Если findings>0: исполнитель применяет находки → контрольный гейт интегратора (1 цикл, без цикла-с-лимитом) Отчёт рана: conclusion + findings[] (path/problem/clause/severity) + verified[] + notCovered[].

Kit.RAG, крупные прогоны: 5–8 акторов, 6–8 фаз — этапы с несколькими исполнителями (например dwfrun-5d13c3f4: 6 акторов/14 ask/7 фаз; dwfrun-ac7e61df: 8 акторов/10 ask/7 фаз). «Инициация-v2» (04.11): 2 актора.

Kit.DevAi (7 прогонов, 23–24.10, проект TaskHub): крупнейший dwfrun-5021e485 — 12 акторов, 13 ask, 12 фаз (фазы: «Фундамент: миграция БД…» → «Хаб…» → «Раннер…» → «DevHub…» → «Гейты: dotnet-тесты…» → «Приёмка диффа по требованию владельца» → «Исправление замечаний приёмки» → «Повторные гейты» → «Повторная приёмка свежим взглядом» → «Контракты §18» → «Развёртывание на стенд» → «Итоговый отчёт») — полный цикл с приёмкой диффа владельцем внутри одного рана. dwfrun-b3c7d50f — аудит/планирование: 10 акторов, фазы «Сверяем остаток работ» → «Независимая проверка плана» → «Правим план по замечаниям» → «Пишем документ плана» (ревизия плана свежим контекстом).

Kit.ZСode.Plagins (01.11, file-editor): 4 параллельных исполнителя (Promise.all: каркас / CodeMirror-vendor / логика / панель) → сервер+интеграционный тест → детерминированные гейты world.run (python smoke.py, python mcp_check.py) с циклом доводки до 3 итераций агентом-фиксером → независимое ревью → до 2 итераций правок high/medium с перепроверкой ревьюером → publishArtifact + результат. 1 амдмент (dwfrun-1ead86e0 resumed from dwfrun-3649c525): diff 352→353 строки, 11 хунков — ТОЛЬКО правки промптов: (а) пометки «прошлый прогон мог оставить файлы — прочитай и доведи, а не создавай вслепую» (ревизия после возобновления с кэшем), (б) уточнения контракта по фактам первого прогона (tools/list-обёртка, availableDisplayModes, utf-16 BOM-вариант, зависимости CodeMirror-режимов, эхо line). dwfeval-скрипт — 13 строк проб среды (python/curl/glob) перед стартом.

2.4. Повторяющиеся приёмы (встречаются в ≥3 независимых прогонах/проектах — факт по grep/diff)

Приём Где видно (примеры) Число
МАНДАТ/зона исполнителя в промпте («правишь ТОЛЬКО …, ЗАПРЕЩЕНО …») Kit.RAG типовой этап; Kit.DevAi COMMON («НИЧЕГО не коммить»); file-editor CONV десятки прогонов Kit.RAG (все этапные)
Интегратор-гейт сборка+тесты после исполнителей Kit.RAG модальный паттерн (интегратор ask); Kit.DevAi 5021e485/318aff72 (фазы «Гейты»); file-editor (world.run) 84+7+1
Независимая ревизия свежим контекстом (отдельный актор, файлы не правит) Kit.RAG модальный паттерн (ревизор); Kit.DevAi «Повторная приёмка свежим взглядом», «Независимая проверка плана»; file-editor «независимый ревьюер» повсеместно
Контрольный гейт после правок Kit.RAG (gate2); Kit.DevAi («Повторные гейты после правок»); file-editor (повторный run тестов) повсеместно
Эскалации: инструкция агенту «эскалируй, не обходи молча» в промпте grep «эскалир» — в 60/84 прогонах Kit.RAG; структурных эскалаций (hole/question-фасад для развилки) — 1 факт: dwfrun-4a3c9e90 (Kit.RAG, 1 hole); живой прецедент dwfq-эскалации описан в ретроспективе И5 (dwfq-5fba54b3-1, санкция оркестратора на вне-зонный фикс) см. числа
Детерминированные гейты через world.run (вне агента) file-editor (2–8 worldRead-run на прогон); Kit.DevAi 318aff72/5021e485 (5–7 world-вызовов); в типовом этапном паттерне Kit.RAG гейты выполняет агент-интегратор с Bash, world.run=0 3 из 3 проектов, но не во всех прогонах
Параллельные зоны (Promise.all) file-editor этап 1 (4 исполнителя); Kit.RAG крупные этапы (par=1–4); пресеты (агенты этапа параллельно) повсеместно где зон >1
Амдмент после прогона (AmendWorkflow) Kit.RAG 5, file-editor 1 6 из 93 (6,5 %)

2.5. Чего в скриптах НЕТ (факт по grep 93 payload)

  • Таймаутов на фазы/агентов: timeout встречается только у world.run-гейтов (timeoutMs: 600000 в пресетах и отдельных прогонах; в Kit.RAG 18 упоминаний «timeout» — в 1 прогоне dwfrun-d7c672e4, в основном 0–6, обычно в контексте не фасада, а текста).
  • Бюджетов (токены/стоимость): 0 упоминаний во всех 93.
  • Интегратора-гейта как отдельной структуры в пресетах: в пресете есть только dotnet build (kit-dev-tdd + dotnet test); «интегратор» как роль в пресете отсутствует — слово «интегратор» встречается в сгенерированных скриптах Kit.RAG (роль-актор), в пресетах нет.
  • Ревизии свежим контекстом как гарантированного шага в пресетах: нет (в пресетах проверка = страховочный тестировщик + контроль дисциплины архитектором; независимого ревизора-агента нет). Факт по тексту ~/.zcode/workflows/kit-dev-process.dwf.ts и kit-dev-tdd.dwf.ts.
  • Авто-записи карточки опыта: нет ни в пресетах, ни в одном из 93 скриптов (grep «карточк|flow_exp|FlowExp» по payload — 0 совпадений, факт).

2.6. Результаты прогонов (success/partial/fail)

  • Журналов завершения ранов (status/result-файлы) в .zcode/workflow-runs нет — есть только .mjs-скрипты → по самим файлам результат рана не восстанавливается (дыра данных).
  • Косвенные факты результатов: ретроспектива Kit.RAG (§2): «39 прогонов (1 ошибся и перезапущен, 6 — resume/amend после капов и правок)» к 01.11; приписки И3–И8: redo 0 (И3/И4), 1 доработочный цикл (И7), красный полный гейт 527/9 (И1), красный гейт этапа 5 И6 — закрыт за 1 прогон. Гейт-тренд 104→607→709→801→808→1025→1153→1164 тестов, 0 skip (1-docs\0-mng\retrospective.md, строки 56, 302–431).

3. Ретроспективные числа Kit.RAG (готовая фактура для метрик петли)

Источник: I:\Kit\Kit.RAG\1-docs\0-mng\retrospective.md (431 строка) + приписки И3–И8.

Показатель Значение Раздел
Прогоны workflow к 01.11 39 (~0,7 млрд токенов; redo/resume 6) §1, §2
Ускорение модуль→модуль ×3–5 (indexing 2 дня → search 1 → ask 1) §1
Находки ревизий 53 (пик, И1-2a') → 1–2 low (И2) → медиана 2/этап (И3–И6) §2, И3/И4
Доля документационных коммитов ~68 % §2
Повторы граблей среды контрольные байты ×3, кодировка ×3 модуля, конкуренция за БД ×2 — «текст не равен профилактике, нужны инструменты» §1(3), §4(7)
Метрики процесса, уже предложенные к ведению (6.3) находок ревизии/этап и доля применено; доля док-коммитов; redo/этап; wall-clock и токены; инциденты среды (класс+повтор); возраст docChanges §6.3
Эскалации живьём dwfq-5fba54b3-1 → санкция оркестратора на точечный вне-зонный фикс (И5) приписка И5
И7: один рабочий день на модуль 11 конвейерных коммитов 10:39–17:00, полных гейтов ×2, доработочных циклов 1 приписка И7
И6: сжатие рецептов −52 % строк рецептов, медиана коммита 1054 симв (против 1793 И5), полных гейтов ≈1,2/этап приписка И6

Интерпретация: все шесть классов метрик из §6.3 ретроспективы (01.11) покрываются (или могли бы покрываться) карточкой §5 — т.е. петля опыта создана 05.11 как раз под уже накопленную потребность, но на момент анализа не собрала ни одной карточки и не синхронизирована со scorecard dx-flow (см. предложения, п.5).

4. Эталон процесса: карточка dx-flow и метрики А–Г

Источник: I:\Kit\Kit.DevAi\std1-ext\_rules\dx\dx-flow.md (живая карточка; светофор датирован 2026-11-02, история — один замер 2026-11-02).

  • Цикл этапа: ТЗ (/stage) → исполнение субагентами по зонам → интегратор (полный гейт) → ревизия свежим контекстом → правки → контрольный гейт → каскад статусов → коммит с рецептом. = модальный паттерн реальных прогонов Kit.RAG (совпадение факт-в-факт, §2.3).
  • 14 метрик: А1 находки ревизии/этап (медиана, ≤2, high=0); А2 псевдо-якоря (=0); А3 дефекты после замыкания (=0); А4 повторы известных граблей (=0); Б1 доля док-коммитов (≤40%); Б2 redo-прогоны/этап (≤1); Б3 wall-clock и токены (тренд ↓); В1 батарея top-3 (100%); В2 темы с первого захода (≥75%); В3 дыры корпуса; В4 возраст docChanges (≤1 итерации); Г1 honest-skip сняты (100%); Г2 эскалации закрыты владельцем (≤1 дня); Г3 инциденты среды → карточка (в тот же день). Формат фиксации: итерация | метрика | значение | светофор | триггер | действие в отчёте замыкания; действия — коммитом std1-ext.
  • Соседние карточки: dx-check.md (чек-лист A1–A3, B1–B8, E — перенесён в std1-ext решением владельца 2026-11-05), dx-map.md, dx-dev-* в std1-ext\_rules\dx\.
  • Прецедент plugin-хука в этом же маркетплейсе: sys-qa-interactive использует хук PostToolUse на AskUserQuestion (hooks/hooks.json, команда python, timeoutMs 15000) — факт: механизм хуков в плагинах семейства обкатан.

5. Согласование: метрики карточки §5 vs А–Г dx-flow

Поля карточки §5.2 (SKILL.md строки 126–130; README журнала): date, project, step, kind, form, preset, model, agents, revisions, escalations, result, duration_min, run_id + уроки.

Поле карточки Ближайшая метрика А–Г Соотношение
agents — в А–Г нет (и не нужно: структурная, не процессная)
revisions А1? Б2? КОЛЛИЗИЯ имён: «revisions» в карточке не определён численно; А1 = находки ревизии (это findings из отчёта рана!), Б2 = redo/amend-прогоны. Одно поле карточки не может означать оба — см. предложения п.5
escalations Г2 дублирует частично: Г2 — «закрыты владельцем ≤1 дня» (время закрытия), карточка — только счётчик
duration_min Б3 дублирует половину: Б3 = wall-clock И токены; токенов в карточке нет
result: success/partial/fail — в А–Г нет; коррелирует с А3/Б2
(нет поля) находки ревизии А1 дыра: единственная метрика с готовой базой (53→2) в карточку не попадает, хотя findings[] есть в отчёте каждого рана
(нет поля) повторы известных граблей А4, Г3 дыра: уроки пишутся текстом, класс/повтор не структурированы
(нет поля) псевдо-якоря А2 дыра (ловится ревизией, в отчёте рана — findings severity)
(нет поля) доля док-коммитов Б1 дыра (считается по git, в карточке нет)
(нет поля) возраст docChanges В4 дыра (метрика замыкания итерации, не рана — в карточку места нет по определению точки опыта)
(нет поля) батарея/темы/дыры корпуса В1–В3 дыра — но это метрики RAG-контура, а не workflow-рана; дублировать в карточку не нужно

Вывод (интерпретация): карточка §5 не согласована с dx-flow: одно поле-коллизия (revisions), два частичных дубля (escalations/Г2, duration_min/Б3), как минимум четыре дыры, из которых самая дорогая — отсутствие А1 (находки ревизии), числово доступной в каждом отчёте рана.

6. Дыры данных (явно)

  1. Результаты (success/partial/fail) 93 найденных прогонов — не восстановимы с диска (журналов ранов нет; .mjs — только скрипт).
  2. Пресетные прогоны: 0 найдено — сравнение preset vs generated по числам невозможно (есть только качественное сравнение каркасов, §2.2/§2.5).
  3. Токены/стоимость прогонов — только одна агрегированная оценка ретроспективы (~0,7 млрд на 39 прогонов), по-прогонно отсутствует.
  4. Поведение flow_stats.py на ненулевом корпусе (сортировка, --last, --write-summary, коллизии kinds «БД»/«db») — не проверено (карточек нет).
  5. Kit.RAG _2bp_logs/_2bp_fix_logs (psql-логи тестов этапа 2b) — следы прогона утраченного скрипта (ретроспектива §5.8: «скрипт утрачен с сессией»); сам скрипт не найден — дыра подтверждена ретроспективой.

7. Итоговая картина (интерпретация, кратко)

Процесс фактически обкатан на 93 прогонах в трёх проектах со стабильным ядром (зоны → интегратор-гейт → ревизия свежим контекстом → контрольный гейт) и зрелой ретроспективной статистикой; петля опыта §5 создана 05.11 как автоматизация уже существующей практики замеров, но (а) держится только на памяти агента сессии, (б) её поля карточки не согласованы со scorecard dx-flow А–Г, (в) пресеты, приоритет которых заявлен в §3.2, ни разу не использованы и отстают от сгенерированных скриптов по контурам контроля (нет ревизора-агента и интегратора как роли). Проверяемые предложения — в предложения_улучшений.md.