Аудит харнесса + сверка

28 июля 2026, 23:15 · хаб A-2022BAYAREA · всё посчитано скриптами, не на глаз

⚠️ Сначала честно: этот замер сделан дважды

Пока я считал на хабе, параллельная сессия на ноуте HP17 посчитала то же самое и в 22:53 выложила _Dashboards\Code-Census.html. Я узнал об этом уже после того, как посчитал. Дублирование — мой промах по правилу §7.7 (сверяться с параллельными сессиями до крупной работы).

Разделение: объём кода и время — источник истины Code-Census.html (там замер по ЧАСАМ, он точнее моего). Эта страница оставлена ради того, чего там нет: аудит харнесса, история отклонённых советов, здоровье 186 роботов, проверка гипотезы Syncthing и сверка двух замеров.

1. Сколько кода написано

198 866

строк Python

уникальных, копии зеркал вычтены

~215 000

строк всего

со всеми языками

1 497

файлов Python

+ 654 файла = точные копии в зеркале GitHub

7 099

функций

5 703 публичных, 1 223 внутренних

На каких языках пишем

Python

198 866 · 95%

PowerShell

4 686 · 2.2%

Batch (.cmd)

4 432 · 2.1%

JavaScript

4 275 · 2.0%

HTML (дашборды)

2 699 · 1.3%

Сверка с замером ноута. Там 393 251 строка и 2 727 файлов, у меня 198 866 и 1 497. Расхождение объяснимо и не является ошибкой ни у кого: число файлов сошлось почти в ноль (2 592 против 2 593), а вот я дополнительно вычел точные копии по md5 — 654 python-файла лежат двумя экземплярами (зеркало E:\GitHub\imports-engines) плюс версии в .stversions. Ещё я не считал строки-комментарии кодом. Итог: ~393К — это «сколько лежит на дисках», ~199К — «сколько написано уникального». Обе цифры честные, вторая ближе к вопросу «сколько кода мы написали».
Побочно: 654 точные копии — это нарушение нашего же правила §5.8 «один источник, ноль копий».

Правильный ли язык? Да. Python — ровно тот инструмент для этого класса задач: склейка чужих API, SQLite, текст, вызовы LLM. Ни Go, ни Rust, ни TypeScript тут ничего не улучшат, а починить их «отвёрткой» будет сложнее. Язык менять не надо. Проблема не в языке — она ниже.

2. Тесты — самая красная зона

2.4%

функций под тестом

173 тестовых из 7 099

2.5%

живых деталей с тестом

18 из 708 · по Coverage-Map

тестовых файлов

на 1 497 файлов кода

нет

pytest не установлен

запустить всё разом нечем

Что именно сломано в тестах

pytest в системе отсутствует — проверено импортом. Как и coverage, mypy, black, pylint. Из привычного стека стоит только ruff (и то как чужая зависимость).
55 тест-файлов написаны «руками» — каждый со своим check() и печатью ✅/❌. Работают, но запускаются только поштучно и только когда кто-то вспомнит.
Раннер тестов есть, но только на ноуте. Я сначала написал «раннера не существует» — это было неверно. Проверил: regress_run.py и coverage_map.py физически отсутствуют на хабе и в волте, они живут только на HP17-ZBook. На хабе пересчитать собственное покрытие нечем — доезжают только готовые отчёты. Это та самая дыра P0 «у пиров нет автоканала доставки ~/.claude/scripts».
⚠️ Канон ссылается на то, чего тут нет: CLAUDE.md §5.8 велит запускать python ~/.claude/scripts/coverage_map.py — на хабе эта команда просто не сработает.
Первый прогон регресс-сетки (ноут, 28.07): 28 зелёных, 4 молча красных. Четыре проверки падали, и никто об этом не знал.
Нет pyproject.toml, нет requirements.txt, нет CI, нет pre-commit — 1 497 файлов не упакованы ни во что.
Покрытие по строкам измерить нечем — модуль coverage не стоит, так что цифра 2.4% посчитана по функциям, а не по строкам. Настоящее покрытие строк почти наверняка ниже.

Отраслевой ориентир: у обычной команды 60–80% покрытия строк, и падение теста блокирует мерж. У нас 2.4% по функциям и ничего ничего не блокирует. Действует наше же правило §5.8: «проверка без прогона = нет проверки» — значит 55 тестов формально не существуют.

3. Сколько «микросервисов»

Слой	Штук	Состояние
Задачи планировщика (наши ночные роботы)	186	152 включены, 34 выключены
Скиллы	101	markdown-обёртки над скриптами
Базы SQLite	61	у каждой свой формат и свой хозяин
Хуки сессии	22	python
MCP-серверы (коннекторы)	~19	Telegram, WhatsApp, Gmail, Calendar, Drive, Trello, Granola, Fireflies, Calendly и др.

Формально «микросервисов» у нас нет — нет сети, нет API между ними. Но по нагрузке на сопровождение 186 запланированных роботов = именно микросервисная архитектура, только без единого журнала, без общего протокола ошибок и без владельца.

Здоровье этих 186 роботов

119

отработали за 24 ч

молчат больше 7 дней

последний код ≠ 0

не запускались ни разу

То есть примерно каждый четвёртый робот (52 из 186) либо протух, либо падает, либо мёртв с рождения. Это и есть «шаг назад», который приходится ловить руками.

4. Главный ответ: инфраструктура против движения вперёд

Из 6 551 сессии на этой машине живых разговоров с тобой — 539

2 503 робота (боты-ассистенты, кроны) 2 912 одноходовок из скриптов 566 субагентов 539 твоих разговоров

83% всех сессий — это система, разговаривающая сама с собой. Само по себе не плохо (роботы должны работать), но объём обслуживания виден именно тут.

Твоя гипотеза «шаг вперёд — три назад»: подтвердилась, ровно 3:1

Тема разговора	Сессий	Доля	Ходов	Доля ходов
🔧 Волт / правила / скиллы / память	141	26.2%	2 063	20.0%
🔬 Ресёрч (в основном про саму систему)	110	20.4%	3 030	29.4%
🔧 Прямая починка / инфра	68	12.6%	1 128	10.9%
📝 Контент	53	9.8%	1 229	11.9%
🤝 Аутрич и лиды	34	6.3%	518	5.0%
🚀 Продукт / GitHub / релизы	23	4.3%	298	2.9%
Прочее	110	20.4%	2 056	19.9%

Обвязка (инфра+волт+ресёрч)

319 сессий

Наружу (аутрич+продукт+контент)

110 сессий

2.9 : 1 по сессиям · 3.04 : 1 по ходам

Ты сказал «шаг вперёд и три назад» по ощущению. Мой замер по сессиям: 3.0 к 1. Ощущение попало в точку.
Узкая трактовка (считать «назад» только явную починку, без волта и ресёрча) даёт 1.9:1 — тоже плохо, но мягче.

А замер ноута по ЧАСАМ даёт 7.3 : 1 — и его надо считать главным, он точнее: там классифицированы действия внутри сессий и взвешено время, а я считал штуки сессий и ходы. Одна короткая инфра-сессия и одна многочасовая весят у меня одинаково.

И там же диагноз острее моего, я с ним согласен: время съедает не починка (274 ч, 14.9%), а стройка новых инструментов — 1 073 ч, 58.4%. Наружу ушло 161 ч (8.8%). По месяцам починка падает (156→110 ч), а стройка растёт (471→562 ч). То есть «три шага назад» — это не столько «чиню сломанное», сколько «строю ещё одну штуку вместо того, чтобы идти наружу». Это меняет лечение: харнесс лечит поломки, но перекос лечится только отказом от стройки.

Июль отдельно — стало ли лучше

Месяц	Обвязка	Наружу	Отношение
Июнь 2026	133	33	4.0 : 1
Июль 2026	178	74	2.4 : 1

Тренд в правильную сторону: с 4:1 до 2.4:1. Продуктовых сессий стало вдвое больше в доле. Но обвязка в абсолюте всё равно растёт.

5. Харнесс: что уже стоит

Есть и работает

ритуал /tt — прогнать, сломать нарочно, вердикт ✅/⚠️/❌
3 ломателя Codex + Grok + Gemini через secondop.py — чужие глаза на свежий код
10 гейтов claude_md_guard, memory_guard, rule_home_guard, declined_guard, lint_path_hardcode, lint_approval_routing, fb_guard, social_guard, bus_guard, deploy_sweep_guard
карта coverage_map.py → живые/мёртвые детали, тест, док
карта System Architect /arch, скор 98/100
бэкап git-снапшот каждые 15 минут, 293 коммита с 23 июня
только на ноуте regress_run.py — регресс-сетка. На хабе её нет

Нет вообще

нет регресс-сетки на хабе — на ноуте она появилась сегодня и сразу нашла 4 молча красных проверки; на главной машине её нет
нет pytest ни на одной машине
нет канала доставки скриптов на пиры — инструмент, написанный на одной машине, на другие не доезжает
нет измерения покрытия (coverage не стоит)
нет упаковки: ни pyproject.toml, ни requirements.txt
нет проверки LLM-выходов (eval) — качество ответов не меряется вообще
нет единого журнала: сколько токенов и минут стоит каждый ночной робот

Граница, которую важно понимать

Ломатель (Codex/Grok/Gemini) — это разовое ревью в момент сборки. Он смотрит на свежий код и говорит «тут криво».

Харнесс — это «вчера работало, сегодня нет». Он ловит регрессии, тихие падения ночных роботов, дрейф качества LLM и гонки за блокировки — то, что ломатель не видит в принципе.

У нас есть первое и нет второго. Одно другое не заменяет.

6. Какие харнессы советовали раньше и что мы с ними сделали

Когда	Кто и что предлагал	Решение	Почему
03.07 коммент 10.07 зум 21.07 TG	Кирилл Симаков (Monosnap, 2.5M MAU) — 20 оптимизаций харнесса с самозамеренным A/B; «Agent Learning Infrastructure» (апгрейд чужих харнессов через A2A); фрактальный рой агентов; zero-trust на апдейты харнесса. Прямая оферта: «will help you to evolve/upgrade your agents/harness or create a custom one»	открыто	Живой человек с прямым предложением. Лежит в `02-Decisions\decision-harness-optimizations-from-kirill-dr-2026-07-04.md`
2026	Денис Смирнов — AgentPlane.org, платформа-харнесс с оркестрацией агентов и облачным слоем	не разбирали ни разу	Единственный совсем неотработанный советчик. `07-People\person-denis-smirnov.md`
14.06.2026	Тяжёлый knowledge-pipeline: Playwright, Tesseract OCR, FAISS/Qdrant, BERTopic, SQLCipher	отклонили	АК-47: «стек, который не починить отвёрткой». Взяли 4 дешёвые надстройки. DR независимо подтвердил ~70% нашей архитектуры
16.06.2026	«Единая review-поверхность + eval-харнес»	отложили	Параллельная сессия строила движок альфы, боялись дубля. Это ровно то, о чём ты спрашиваешь сейчас
18.06.2026	Codex: milestone-retro как 3-слойный контур — PostgreSQL, Redis/SQS, Jira/Slack, OpenTelemetry, approval-engine. Оценка: 6–8 недель, 1.5–2 FTE, $250–2000/мес	отклонили	Спроектировано под обычную SWE-команду, не под тебя. Взяли одну надстройку: `/retro` Step 4★
28.07.2026 сегодня	Decision Memo «QA-процесс и тест-харнес» — синтез 10 отчётов от 3 вендоров (Grok Heavy, ChatGPT Pro DR, Gemini Pro DR)	ждёт твоего «+»	Статус `proposed`. Ничего не построено

Файл памятки: E:\Obsidian\Anton-Knowledge\02-Decisions\decision-2026-07-28-qa-process-and-test-harness.md

Что памятка от сегодня рекомендует (коротко)

Слой	Берём	Не берём и почему
Обычный Python	pytest	unittest — многословный, nose2 — мёртв
Проверка LLM-выходов	promptfoo (YAML/CSV, MIT, локально)	DeepEval — UI завязан на SaaS; Inspect AI — порог входа
Журнал прогонов	свой SQLite	Langfuse (Docker+Postgres+Clickhouse+Redis), LangSmith, Braintrust — вендор-лок и приватность
Ночные роботы	heartbeat + утренняя проверка	внешний SaaS-мониторинг — приватность

Плюс детерминированный стоп-кран отладки: 3 неудачные попытки подряд · больше 5 файлов · 50% контекста · 20 минут без прогресса → выносим в отдельную сессию. Все 3 вендора независимо назвали ровно 3 попытки.

7. Проверил на наших данных: гипотеза про Syncthing

Gemini предупредил: Syncthing поверх живых .git и SQLite-WAL тихо портит блокировки, и часть «случайных зависаний» — это оно.

Проверил на хабе — у нас этой дыры нет. Все *.db-wal нулевого размера; *.db, *.db-wal, *.db-shm уже в .stignore; .git исключён в .stignore.shared; ни одного sync-conflict по базам или гиту; git fsck чистый.

Это была самая дешёвая проверка из всей памятки, и она закрыта: причина «случайных зависаний» не здесь. Искать надо в другом месте. Оговорка: проверен только хаб, на других узлах не смотрел.

8. Мой вывод как кофаундера

Харнесс нужен, но он не корень проблемы

Корень видно в цифрах: 1 497 файлов кода, 186 ночных роботов, 101 скилл, 61 база — на одного не-технаря. Из 867 python-деталей 159 уже мёртвые (18%). Из 186 роботов 52 протухли, падают или не запускались ни разу (28%).

Мы производим детали быстрее, чем способны их содержать. Харнесс это покажет, но сам по себе не уменьшит. Поставить pytest поверх 1 497 неупакованных файлов — это добавить ещё одну деталь в тот же зоопарк.

Замер ноута по часам это подтверждает численно: стройка 1 073 ч против починки 274 ч. Ты просил улучшить харнесс, потому что «починка съедает время» — но починка это только 15% времени. Съедает стройка новых инструментов. Значит харнесс, каким бы хорошим он ни был, вернёт максимум пятую часть потерянного.

И сегодняшний день — живая иллюстрация: два узла независимо посчитали одну и ту же перепись и сделали два дашборда. Это ровно та стройка, о которой речь.

Порядок, который я предлагаю

Сначала снести мёртвое — 159 деталей и 34 выключенных робота. Это минус сопровождение, ноль риска, и оно уже посчитано в Coverage-Map и Dead-Code-Candidates.
Потом Неделя 1 из памятки — pytest + 5–7 тестов на служебный слой + heartbeat на 5–7 критичных роботов. Полезно само по себе, даже если дальше не пойдём.
Одновременно — стоп-кран (3 попытки / 5 файлов / 20 минут). Он бесплатный, это правило, а не код, и по данным трёх вендоров он лечит вторую треть долгой отладки.
Жёстче держать гейт §3.5 «строим только то, что кровь-из-носу сейчас». 3:1 не выправится, пока производство деталей не замедлится.

Возражение, которое я жду от тебя: «сначала харнесс, потом чистка — вдруг снесём живое». Контраргумент: coverage_map.py уже размечает живое/мёртвое по ссылкам и дате правки, а мёртвое по определению никем не вызывается — тест на него писать некому и незачем. Но если не согласен — переубеди, спорить готов.

🧒 Простыми словами

Мы построили очень большую мастерскую: почти 200 тысяч строк, 1 500 деталей, 186 роботов, которые работают ночью.

Но проверялок у нас почти нет — тесты есть только у 2 деталей из 100. И даже те 55 проверок, что написаны, запустить разом нечем: программа для запуска тестов у нас просто не установлена.

Ты сказал «шаг вперёд, три назад». Я посчитал по разговорам: три к одному. Другая машина посчитала по часам и вышло семь к одному. Ты не преувеличивал, ты преуменьшал.

Но самое важное вот что. Ты думал, что время съедает починка. Оказалось — нет. Починка это только пятнадцать минут из каждого часа. Съедает стройка новых штук: почти шестьдесят минут из ста. Мы всё время строим новый инструмент вместо того, чтобы выйти наружу и поговорить с людьми.

Значит проверялки помогут, но мало. Они лечат поломки, а у нас болезнь другая: мы слишком много строим.

Ещё: из 186 ночных роботов каждый четвёртый молчит, падает или ни разу не работал.

Что делать: сначала выкинуть 159 сломанных и никому не нужных деталей, потом поставить простую проверялку и «пульс» роботам, а главное — перед каждой новой стройкой спрашивать «а кто этим будет пользоваться?» и не строить, если ответа нет.

Как это посчитано и где границы: код — обход файлов с вычетом точных копий по md5. Сессии — разбор 6 551 файла ~/.claude/projects/*.jsonl по первому сообщению: роботы, одноходовки скриптов и субагенты отделены и в статистику разговоров не входят. Темы размечены по ключевым словам первого сообщения — метод грубый, ошибка на отдельной сессии возможна, на 539 сессиях пропорция устойчива. Окно данных начинается в конце мая 2026 (более ранняя история ноутбука сюда не доехала), так что абсолютные числа — это «с конца мая», а не «за всё время». Покрытие считано по функциям, не по строкам: измерить строки нечем.