С другой стороны это похоже на ещё одну игру в жанре «ИТ-стратегия», которую я так хочу пройти. Не знаю, какие уровни будут дальше, но вчера я, похоже, взял ещё один уровень. Наконец-то разобрался с одним из элементов CI/CD — автотестами и графическими отчётами к ним.

Ниже в основном творчество Клода, я попросил его писать попроще, потому что для меня тоже многие слова не то чтобы каждый день на языке. У меня теперь разработка так устроена — в основном это приключения на вечер в стиле Рика и Морти, на 20 минут вошли и вышли, которые перетекают в очередную эпопею. Я не проходил курсов, не считаю каждый токен, предварительно выстраивая всю архитектуру на бумажке — я просто чётко (а иногда не очень) формулирую свою задачу и контролирую, чтобы в процессе реализации Клод не ушёл в очень уж густые дебри.

А ещё он меня похвалил, когда кружил вокруг одной проблемы около часа, перепробовал всё и пытался меня отговорить от фичи. Я ему сказал, что не привык сдаваться, и дал небольшую подсказку — через минуту готовое решение было у меня на экране. Никогда бы не подумал, что буду хвалиться тем, что меня похвалила машина.

У меня в ИИконе — это открытое расширение к 1С для интеграции с LLM, над которым плотно сижу с весны — 72 теста YAxUnit. Прогон на полминуты руками, считаю прошедшие и упавшие глазами по длинному JSON. К утру следующего дня вместо этого работал зелёный автопрогон по каждому коммиту в Gitea, дашборд Allure на NAS с историей и Telegram-бот, который ругается, когда тесты падают.

Финальная картинка: 72/72 PASSED, около 29 секунд от коммита до отчёта в Allure.

По дороге наступил на шесть граблей и одну галлюцинацию DeepSeek.

Что было до

Тесты разнесены по 14 общим модулям. YAxUnit умеет писать отчёт в формате JUnit XML — а это как английский для систем прогона: понимают почти все.

До этого прогон выглядел так. Я открывал Claude Code, говорил «прогони тесты». Запускался MCP-инструмент run_module_tests, который под капотом дёргает 1cv8.exe ENTERPRISE /C "RunUnitTests=config.json". На выходе — JSON, в нём список модулей, для каждого — список тестов с результатами.

Я смотрел на JSON и решал, доволен ли я.

Иногда — открывал HTML-отчёт, который YAxUnit любезно генерирует рядом. Иногда — нет. Часто — забывал, что прогонял утром, и не помнил, был ли тогда красный или зелёный.

Не то чтобы это было больно. Просто очевидно бестолково, если задумываться. Нет истории прогонов. Нет графика по неделям. Нет процента успешных тестов в динамике. Каждый прогон — снимок, который я тут же забываю.

И ещё — задним числом я не помнил, что я последний раз сломал. Если сегодня 70 из 72, а вчера было 72 из 72 — где регрессия? Какой тест начал падать? Когда? Чтобы это понимать, надо вести историю. А чтобы вести историю — надо чтобы прогон жил не в моей голове.

Вот, собственно, и решил.

Из чего собирал

Я собрал такой зоопарк:

• Gitea на NAS. Простой git-сервер, лёгкая система автопрогонов Gitea Actions внутри.
• act_runner под Windows. Это исполнитель шагов, который умеет крутиться где угодно. У меня — на ноуте, потому что 1С живёт там же.
• vanessa-runner (vrunner). Обвязка для запуска 1cv8.exe с человеческим лицом. Умеет YAxUnit, BDD, и кучу другого.
• YAxUnit kernel — собственно тестовый раннер для 1С. Пишет JUnit XML.
• Allure server на NAS. Тот самый Docker-контейнер от frankescobar/allure-docker-service. История прогонов, тренды, графики.
• Прометей + Графана + Алертменеджер + Telegram-бот. Понятно зачем — чтобы когда что-то упало, я узнал об этом из телефона, а не из размышлений «а как там у меня тесты».

Вот как это бегает по прямой:

Всё локальное. Никаких облаков, никаких счётчиков минут на чужих исполнителях. У меня дома NAS, у меня ноут, у NAS — Docker, у ноута — 1С. Этого достаточно.

Что в итоге за вечер

За вечер прошёл семь этапов: включил Gitea Actions, поднял Windows-исполнитель, подключил прогон через vrunner, перенёс исполнитель в службу, поднял Allure на NAS, написал переводчик JUnit XML в формат Allure, сверху прикрутил Prometheus с Telegram-ботом. Подробности — в граблях ниже, пошаговый туториал — в README шаблона.

Получилось — коммит в репо → через минуту в Allure лежит свежий отчёт, в Grafana прирастают метрики, в Telegram — тишина, пока зелёное.

А теперь грабли. По штукам.

Грабля 1 — кириллица в пользователе

В 1С база лежит файловая, пользователь — «Администратор», пароль — пустой. Так настроено лет десять и до сегодня не мешало.

Запускаю прогон через vrunner. В консоли:

Пользователь ИБ не идентифицирован

Код выхода 1, прогон умирает за полторы секунды.

Грешу на vrunner. Грешу на YAxUnit. Грешу на конфиг. Перепробовал три варианта параметров, четыре — не помогает.

Запускаю ту же команду напрямую, без vrunner:

"C:/Program Files/1cv8/8.3.27.1989/bin/1cv8.exe" ENTERPRISE \
  /IBConnectionString "File='F:/...'" \
  /N "Администратор" /P "" /C "RunUnitTests=..."

Тот же ответ. Та же полторы секунды.

Меняю пользователя в базе на латинского mcp-client, пароль 12345. Запускаю.

Зелёный прогон.

Что произошло. Похоже, где-то в цепочке запуска 1cv8.exe через PowerShell / vrunner / Python всплывает однобайтная кодировка — и кириллический Администратор теряется при преобразовании. Для 1С такого пользователя в базе просто нет, дальше падение.

Хочется сказать «1С виновата». Но реально — это болезнь почти любого .exe старше десяти лет, который не научили читать аргументы как Unicode. PowerShell тут просто прокладка.

Лечение скучное и работает на 100%: в пользователе для автопрогонов не должно быть кириллицы. Создаёшь в базе пользователя mcp-client или ci-user, выдаёшь ему права (для тестов — полные, не жалко), и в шагах прогона ходишь под ним.

Лечение для себя: я держу кириллического «Администратора» как основного для работы руками и латинского mcp-client для автопрогонов. Они не мешают друг другу.

Самое смешное: за этот вечер я потерял на этой грабле минут сорок. Через две недели после этого, копаясь в старых заметках по статьям, нашёл собственную запись от 6 мая: «Codex решил эту проблему. Описал в инструкциях и в CLAUDE.md. Через латинского пользователя.» Прошлый я знал. Текущий я забыл и пошёл по тем же граблям. И понял, почему есть отдельный шаг во всех моих инструкциях — «первым делом загляни в свою папку наработок».

Грабля 2 — права запуска скриптов под LocalSystem

Окей, прогон работает. Тесты зелёные. Открыт терминал, в нём крутится act_runner.exe. Если я закрою терминал — исполнитель умрёт, и коммит в Gitea не подхватится.

Надо поднять исполнитель как Windows-службу, чтобы он жил вечно.

Беру WinSW (это маленькая обёртка для запуска чего угодно как службы), регистрирую исполнитель под аккаунтом LocalSystem, стартую. Коммит в репо. Шаг 1 — пять секунд. Падает.

В логах:

PSSecurityException: UnauthorizedAccess
File ...\0.ps1 cannot be loaded because running scripts is disabled
on this system. ExecutionPolicy: Restricted

Ставлю права запуска на RemoteSigned через групповую политику. Перезапускаю. То же самое.

Ставлю Set-ExecutionPolicy -Scope Process Bypass первой командой в скрипте. То же самое.

Что-то тут странное.

Открываю как Gitea на самом деле запускает шаг PowerShell:

powershell -command . '0.ps1'

Видите эту точку перед '0.ps1'? PowerShell это называет «загрузить в текущую сессию». Это означает: проверка политики запуска происходит до того, как тело скрипта начнёт выполняться. То есть мой Set-ExecutionPolicy внутри 0.ps1 физически не успевает сработать. Скрипт даже не запускается.

Нашёл лечение — shell: cmd плюс явный вызов powershell -ExecutionPolicy Bypass -File:

- name: Run smoke
  shell: cmd
  run: powershell -ExecutionPolicy Bypass -File run-yaxunit-smoke.ps1

Это уже не загрузка в текущую сессию — это запуск отдельного PowerShell-процесса с уже выставленной политикой. Работает. Без UAC, без правки реестра, без правки локальной групповой политики на всех компах.

Запускаю. Падаем на следующем шаге:

'oscript' is not recognized as an internal or external command

Грабля 3 — PATH потерял пользовательскую часть

Это уже сцепка к предыдущему. LocalSystem видит машинную часть PATH. А oscript.exe я ставил через ovm (это менеджер версий для OneScript). ovm кладёт всё в C:/Users/<user>/AppData/Local/ovm/current/bin — то есть в пользовательскую часть PATH.

Запускаю под собой — работает. Запускаю под LocalSystem — oscript не найден.

Решений два. Первое — добавить путь от ovm в машинную часть PATH. Так нельзя, потому что я там ставил конкретно локально, под себя, и не хочу делать это глобальным.

Второе — расширить $env:Path в скрипте-обёртке, явно ткнув в нужную папку:

$VrunnerExe = "C:/Users/<user>/AppData/Local/ovm/current/bin/oscript.exe"
$env:Path = "$(Split-Path -Parent $VrunnerExe);$env:Path"

Сразу после этого vrunner находит oscript, oscript находит свой пакет, прогон стартует.

В сумме — три грабли подряд. Кириллица в пользователе, политика запуска под службой и пропавший PATH — на отдельный вечер каждая, если не знать. Все три отлично гуглятся задним числом. Но в моменте, когда видишь «выход 1 за полторы секунды без объяснения», не очевидно, что это, цитирую, проблема границы Unicode и однобайтной кодировки в системном вызове Windows.

Зелёный прогон через службу — после этого. Пять часов в сумме на сегодняшний вечер.

Грабля 4 — DeepSeek убедил меня чинить не ту Synology ACL

Это моя любимая.

Allure поднялся за две минуты — docker run на NAS, frankescobar/allure-docker-service, проброс папки /volume1/docker/allure/projects внутрь как /app/projects. Стартует, на порту 5050 живая морда.

Делаю первый POST — отправить результаты прогона. Получаю:

HTTP 400
Permission denied: '/app/allure-docker-api/static/projects/yaxunit-iikona'

Делаю перезапуск контейнера. Тот же POST. Зелёный. Загрузка прошла.

Хм. Подозрительно — после перезапуска работает, а до — нет.

Запоминаю это в голове и думаю: «Видимо первый раз после старта он что-то досоздаёт».

На следующий день поднимаю второй проект на том же Allure. Та же ошибка. Тот же перезапуск. Лечит.

Это уже не «видимо». Это закономерно. Каждый новый проект — перезапуск.

В Claude Code прикасаюсь к скиллу про связку нескольких агентов: «поручу DeepSeek через opencode run, пусть посмотрит свежим взглядом и найдёт настоящую причину». DeepSeek (v4-pro через OpenRouter) у меня в скилле для именно таких ситуаций — независимое мнение по конкретной проблеме.

Отправляю описание ошибки и контекст. Через двадцать секунд ответ. Уверенный, со ссылками на скрипт запуска этого образа Docker:

«Скрипт запуска выполняет chown -R 1000:1000 /app/projects асинхронно. Flask-приложение стартует раньше, чем заканчивается смена владельца. Поэтому первый POST приходит до того, как владелец поменялся, и процесс с правами 1000 не может писать. После перезапуска скрипт инициализации уже отработал, права выставлены — POST проходит.

Решение: в docker-compose.yml добавить command: ["sh", "-c", "chown -R 1000:1000 /app/projects && exec entrypoint.sh"] — синхронная смена владельца перед стартом сервиса.»

Логично. Стройно. Объясняет всё, что я видел.

Я уже почти было пошёл это применять. Но что-то меня остановило. Не знаю что. Какой-то рефлекс «проверь руками сначала».

И я зашёл в контейнер по SSH:

docker exec -it allure ls -ld /app/projects/yaxunit-iikona

Ответ:

drwxrwxrwx 2 1029 users 4096 May 14 22:30 /app/projects/yaxunit-iikona

Стоп.

Владелец — 1029. Не 1000.

То есть никакой смены владельца в скрипте запуска не происходило. Ни до старта, ни после. Владелец — 1029:users, как я его создал через mkdir изначально. Права в стиле Unix — 0777, что для процесса с правами 1000 (под которым Flask) разрешает запись.

Я был в полу-шаге от того, чтобы записать в инструкцию 1c-yaxunit-runner «добавьте смену владельца в скрипт запуска, иначе будет 400 на первом POST» — и оставить этот ложный вывод там навечно.

После пары часов проб — стартовал контейнер, ждал пять секунд, делал POST, замерял. Стартовал, ждал десять секунд, POST, замерял. Менял command:, не менял command:. Через двадцать минут реальная картина была вот такая:

Flask-приложение начинает слушать порт 5050 раньше, чем заканчивается скрипт инициализации внутри образа. Скрипт инициализации делает кучу всего — миграции базы SQLite, проверки, прогрев. POST, приходящий на сервер, который уже слушает но ещё не готов, получает 400 с криво сложенным сообщением «permission denied на /app/…», хотя реально с правами ни при чём.

Лечение — банальный опрос готовности перед первым POST:

for _ in range(30):
    if requests.get(f"{ALLURE_URL}/version").ok:
        break
    time.sleep(1)

Тридцать секунд ожидания готовности на старте. После этого POST-запросы летят.

DeepSeek был умен, стройн и неправ. Я его очень люблю как независимого ревьюера, особенно в обычной связке нескольких агентов: каждое ревью кода через DeepSeek поверх Claude находит баги уровня «уборка дубликатов событий цепляется не за идентификатор, а за совпадение сумм за тридцать дней». Но в этот раз он сочинил красивую внутреннюю модель ошибки, которая не имела отношения к реальности.

Я: «Так ты выдумал про смену владельца в скрипте запуска?»

DeepSeek: Молчит. Он не помнит этот разговор. Третий агент в моём рабочем потоке — без памяти между запросами.

Урок: на инфраструктурных вопросах сначала проверка руками, потом совет от ИИ. Пять минут docker exec и ls -l стоят дешевле, чем час неверной правки и потеря веры в собственные диагнозы. Без проверки руками я бы записал в скилл 1c-yaxunit-runner навсегда инструкцию «в скрипте запуска синхронная смена владельца» — и каждый, кто бы шёл моими граблями по моему же скиллу, запомнил бы её как факт.

Грабля 5 — Allure не принимает JUnit XML

Я думал, JUnit XML — это универсальный билет в Allure. Раз Allure про красивые отчёты тестов, и почти все системы понимают JUnit XML — значит и он понимает.

Оказалось, в этом контейнере билет не тот. frankescobar/allure-docker-service принимает только свой формат Allure raw JSON — это один JSON-файл на тест. У него своя структура: name, fullName, status, start, stop, historyId, labels, parameters.

Открыл документацию Allure. Половина — про плагин для Java, половина — про SBT и Gradle. Описание собственного формата — где-то на третьем уровне навигации, под спойлером, на английском, с примером в YAML, который не валиден как JSON.

Окей, написал переводчик сам. На стандартной библиотеке Python, пятьдесят строк:

import xml.etree.ElementTree as ET
import json, hashlib, time, uuid

def junit_to_allure(xml_path, out_dir):
    tree = ET.parse(xml_path)
    for tc in tree.iter("testcase"):
        name = tc.get("name")
        suite = tc.get("classname")
        failure = tc.find("failure")
        status = "failed" if failure is not None else "passed"
        # historyId через md5 — чтобы Allure связал прогоны в график
        history_id = hashlib.md5(f"{suite}.{name}".encode()).hexdigest()
        result = {
            "uuid": str(uuid.uuid4()),
            "name": name,
            "fullName": f"{suite}.{name}",
            "status": status,
            "stage": "finished",
            "historyId": history_id,
            "labels": [{"name": "suite", "value": suite}],
        }
        if failure is not None:
            result["statusDetails"] = {"message": failure.get("message"), "trace": failure.text}
        with open(f"{out_dir}/{result['uuid']}-result.json", "w") as f:
            json.dump(result, f)

historyId = md5(fullName) — критическая мелочь. Без неё Allure не свяжет прогоны между собой, и не будет графиков трендов. Это написано в их документации, но не очевидно — раздел про историю как раз про этот md5, и легко пропустить, потому что параметр выглядит как «необязательный».

Переводчик работает. Заливка работает. Тренды строятся. Дальше в цепочке от меня нужно только смотреть на красивые графики и иногда отвечать в Telegram-бот «yes, видел, сегодня починю».

Грабля 6 — BDD-тесты в автопрогон не лезут

В ИИконе кроме YAxUnit (модульные тесты) есть сценарии BDD через Vanessa Automation. Это поведенческие тесты, написанные на Gherkin. Они умеют ходить по формам, нажимать кнопки, читать значения — то есть нужен живой экран с интерфейсом.

Под YAxUnit мы только что собрали красивую штуку — исполнитель крутится как служба под LocalSystem, прогон без видимого окна, прекрасно. Хочется BDD туда же.

Не работает.

LocalSystem в Windows стартует в Session 0 — это специальная сессия для системных служб, без интерактивного рабочего стола, без окон, без сообщений интерфейса. Сценарии Vanessa отправляют оконные сообщения формам — в Session 0 этих окон нет.

Vanessa запускает 1С тонкий клиент, тонкий клиент пытается открыть форму, движок интерфейса отправляет оконные сообщения — некому слушать. Тест зависает или падает с непонятной ошибкой через таймаут.

Можно? Технически — psexec -s -i 1 vrunner.exe, переключение в Session 1, тонкий клиент в видимом рабочем столе. Можно службу запускать не от LocalSystem, а от обычного пользователя с разрешением «вход как служба». Тогда сессия получает интерфейс.

Должен ли я это делать? Для моего случая — нет. Сценарии BDD у меня прогоняются раз в неделю руками через Vanessa MCP в Claude Code. Я в этот момент сижу за компом, смотрю как кликается. Это и нужно, потому что BDD у меня про вёрстку форм — я в этот момент смотрю скриншоты.

Решил так:

То есть Allure-история покрывает обе ветки одним и тем же дашбордом. Просто прогон BDD стартует с моей кнопки, не с коммита. И переводчик JUnit → Allure raw используется одинаково.

Получилась несимметричная, но честная цепочка. Без окон там, где это работает. Руками там, где требуется живой экран. Один Allure, два проекта, общая история.

Где помог Claude Code, а где помешал

Здесь не про «ИИ круто помогает разработчику», а про конкретные мелочи.

Где помог. Связка из трёх агентов — Claude как архитектор плюс Codex CLI как разработчик плюс DeepSeek как независимый ревьюер. Я отдаю Codex детально-сформулированную задачу («написать опрос готовности, добавить повторы, обновить модульные тесты»), он реализует, Claude (то есть я в этой сессии) ревьюит, DeepSeek проверяет третьим взглядом. На длинной дистанции эта тройка ловит баги, которые я бы не нашёл. Дороже подписки на Claude Max — копейки на DeepSeek через OpenRouter, около половины цента за прогон ревью.

Скиллы — память между сессиями. После сегодняшних граблей записи про них уже в памяти. Следующая сессия с фразой «настроить автопрогон тестов 1С» сама подтянет нужный скилл, и я не повторю эти же грабли. Это работает не идеально, но лучше, чем без него — Грабля 1 (кириллица в пользователе) тому подтверждение: скилл был, я его не открыл, прошёл по тем же костям. Скилл стал жёстче.

Где помешал. Как показала Грабля 4 — советы ИИ на инфраструктурных вопросах требуют проверки руками. Особенно когда модель не видит твоего конкретного контейнера и твоих конкретных прав.

И ещё — я регулярно ловил себя на том, что изобретаю там, где у меня уже есть готовое. Например я пошёл писать с нуля PowerShell-скрипт для прогона YAxUnit, при том что у меня уже лежат готовые скилл-обёртки db-create, db-load-cf, epf-build для всего этого. Лень открыть ls. Прошлогодний я в инструкциях уже умнее, чем текущий я по памяти. Это смешно и грустно одновременно.

Сколько ушло

Время: 5 часов с клавиатуры в сессиях Claude Code. С вечера четверга до утра пятницы, с перерывом на сон. Реально это две полу-сессии — одна на цепочку YAxUnit до Allure (три часа), одна на Allure плюс стек мониторинга плюс Telegram (два часа).

Деньги:

• Claude Pro Max — подписка, не за задачу. Считать как «фиксированная».
• DeepSeek через OpenRouter — около двух центов за всю сессию. Это пять-шесть прогонов ревью по половине цента, цифра реальная (есть в моём трекере, про который писал отдельный пост).
• Прометей, Графана, Allure — контейнеры Docker на NAS, который и так крутится 24/7.
• 1С — лицензия учебная, файловая база.

Железо: домашний NAS, который и так работает 24/7. Под весь стек — около гигабайта оперативки (Allure плюс Prometheus с Grafana и Alertmanager). На нём же живёт Gitea и пара других сервисов. Запас есть.

Когда стоит это делать

Это не для каждого 1С-проекта. Это для конкретного класса проектов:

• Тестов больше тридцати, и прогон занимает заметное время (десятки секунд → минуты).
• Прогон делается чаще раза в день. Если раз в неделю — перебор.
• Хочется график «процент успешных по неделям», регрессии замечать «вчера было 72/72, сегодня 70/72 — что я сломал?».
• Команда больше одного человека, и тесты надо видеть не только в моей голове.
• Или: команда из одного, но есть стратегическая цель — например, сертификация «1С:Совместимо», для которой автоматизация тестов это плюс.

Если тестов десять и они прогоняются раз в неделю руками — забудь про это, тебе не надо.

Когда не стоит

• Файловая база, единственный разработчик, два десятка тестов раз в неделю. Достаточно ручного прогона.
• Нет NAS / нет виртуалки / нет ноута, который можно отдать под свой исполнитель. На облачных исполнителях 1С запускать нельзя — лицензия привязана к железу.
• Команда не понимает «зачем нам автопрогон» и сопротивляется. Сначала разговор, потом инфраструктура.

Шаблон для тех, кто хочет повторить

Я выложил репозиторий-шаблон. Все шесть грабель задокументированы в README, плюс готовый конфиг прогона, готовый скрипт-обёртка, готовый переводчик JUnit → Allure raw, готовый сборщик метрик Allure для Prometheus.

github.com/andromanpro/onec-yaxunit-ci-template — MIT, бери и адаптируй. Поднимается у нового проекта минут за тридцать.

Поднимается у нового пользователя минут за тридцать. Главные параметры — путь до 1cv8.exe, имя файловой базы, латинский пользователь с правами. Остальное — копипаста.

Посмотреть

• Шаблон onec-yaxunit-ci-template — MIT, README со списком грабель на 200 строк
• ИИкона — AI-коннектор для 1С — открытый проект, из CI-инфраструктуры которого вырос этот шаблон
• Пост про трекер расходов на ИИ — там тот же DeepSeek, который ловит реальные баги, упоминается в контексте связки нескольких агентов
• github.com/andromanpro — публичная часть моих проектов

Что осталось

План, до которого я не дошёл в этот вечер и который висит на следующий заход:

• Перенос всего стека на Linux-исполнитель на NAS плюс 1С в Docker плюс Postgres. Это убирает зависимость от моего ноута. Три-пять дней работы, ждёт повода вроде «команда выросла» или «ноут перестал быть надёжным».
• Сборщик метрик 1С для Prometheus для кластерной базы (если когда-нибудь появится кластер). Для файловой ИБ — бессмысленно.
• Расширение сборщика метрик Allure — помодульные числа, чтобы в Grafana видеть процент успешных по конкретному модулю в динамике.
• Архив HTML-отчётов Allure в /volume1/backups/ (сейчас Allure держит последние 20 отчётов, потом удаляет).

Ни один из этих пунктов не блокирует ничего. Если упадёт что-то критичное, я узнаю через Telegram в течение минуты — это самое важное, что я успел собрать.

Самое смешное

Самое смешное про этот вечер — это не количество граблей. Их шесть, и каждая ловится через 30 секунд docker exec или Get-ChildItem $env:Path.

Самое смешное в том, что из шести граблей пять я уже встречал раньше. Грабля 1 — кириллица в пользователе — была решена 6 мая, в скилле и в CLAUDE.md. Грабля 2 — права запуска под службой — общеизвестная штука среди Windows-сисадминов. Грабля 5 — Allure ждёт свой формат — задокументирована в их официальной документации.

Только Грабля 4 — DeepSeek и не та Synology ACL — была мне новой. И именно на ней DeepSeek дал красивый, уверенный, неверный диагноз. Единственная по-настоящему свежая грабля среди шести — единственная, на которой совет от ИИ дал сбой.

Это не значит, что ИИ бесполезен. Это значит, что ИИ очень хорошо имитирует уверенный ответ, и если ты сам не знаешь правильного ответа, ты не различишь.

Скиллы — внешняя память от прошлого меня к текущему — работают лучше, чем модельная память внутри ИИ. Скилл написан после того, как я проверил руками. Модель пишет ответ из обучающего корпуса, не глядя в мой контейнер.

DeepSeek через два дня после этого вечера поймал в ревью два серьёзных бага в коде, которые я бы не нашёл (обход путей в одной из точек входа, гонка проверок в уборке дубликатов). Я ему очень благодарен. Просто для инфраструктурных диагнозов — docker exec стоит дешевле и точнее.

Автопрогон зелёный. Дашборд Allure жив. Telegram-бот молчит, что означает «всё ок».

А я теперь сижу и думаю, сколько ещё вещей вокруг меня я могу автоматизировать за один длинный вечер.

→ открыть на androman.pro

Я решил сделать маленький трекер для собственного использования ИИ: сколько токенов, сколько денег, сколько времени я реально экономлю, и не обманываю ли я себя красивым ощущением разгона.

Через час он показал почти пять миллионов рублей — точнее, 4 824 000 в эквиваленте API при курсе 80 рублей за доллар.

Я посмотрел на цифру и сказал примерно так:

«Я столько за год не зарабатываю».

Потом выдохнул и поправил себя. Нет, я не потратил пять миллионов. Это важная разница. Столько стоили бы мои Claude Code сессии за два месяца, если бы я платил за них по API-тарифам. Реально я заплатил за Max-подписку: 16 тысяч в месяц, то есть 32 тысячи за два месяца.

Получилось не «я потратил пять миллионов».

Получилось хуже и смешнее.

Получилось: я не потратил примерно 4,79 миллиона рублей, потому что подписка окупилась почти в 150 раз.

И самое странное — это посчитал трекер, который в этот момент сам ещё строился.

Сначала надо было признаться, что я не считаю

У меня давно было ощущение, что ИИ экономит мне время. В апреле я уже считал часы: 147 часов активного общения с моделью за месяц, десятки сессий, куча артефактов, блог, pet-проекты, клиентские задачи, инфраструктура, вся эта прекрасная каша.

Но часы — штука скользкая. Сегодня кажется, что без модели я бы делал задачу неделю. Завтра кажется, что преувеличил. Послезавтра уже не помнишь, что именно было трудно: код, вход в предметную область, проверка результата или просто нежелание начинать.

Деньги в этом смысле грубее.

Есть подписка. 16 тысяч в месяц. Есть фактическое потребление моделей. Есть тарифы API. Можно посчитать, сколько стоил бы тот же объём, если бы всё шло не через Max, а через прямую оплату токенов.

Не как бухгалтерскую истину. Как личный датчик масштаба.

Мне нужен был не корпоративный BI, не «панель эффективности цифровой трансформации», прости господи, а простой локальный счётчик: вот сессия, вот модель, вот токены, вот примерная стоимость, вот день, вот сумма.

Ну и, конечно, я не стал делать это один.

Два агента, один NAS и нормальный взрослый процесс

Схема у меня уже сложилась: Claude Code работает архитектором, Codex CLI работает разработчиком, а Gitea на NAS держит всё в виде задач, PR и слияний. Человек посередине иногда делает вид, что руководит процессом.

Роли простые:

1. Claude формулирует фазу, режет задачу, ревьюит результат.
2. Codex лезет в репозиторий, пишет код, чинит тесты, приносит PR.
3. Gitea не даёт этой каше превратиться в «я тут что-то правил в папке».
4. Я смотрю на цифры и периодически говорю: «алло, это точно не взорвётся?»

За один длинный сеанс пролетели несколько фаз.

Phase 1.0 — хук окончания сессии для Claude Code. Когда сессия заканчивается, хук читает данные, находит последнее событие ассистента с расходом токенов, считает примерную стоимость и пишет событие в локальный JSONL.

Phase 1.3 — хук на старте сессии и оценка сложности через claude -p --bare. Идея: на старте новой сессии найти предыдущие сессии без оценки и в фоне попросить Claude прикинуть, сколько часов такая задача заняла бы без ИИ.

Phase 1.0.1 — обратная загрузка истории из ~/.claude/projects/*/*.jsonl. Это и стало большим взрывом цифр: не только новые события, а весь хвост за два месяца.

Phase 1.0.2 — срочная правка, потому что внезапно выяснилось, что у нас есть не только данные, но и способы ими случайно замучить собственную подписку: ограничитель частоты, пропуск синтетических сессий, уточнение цен, правильный разворот формулы экономии.

Каждая фаза шла через задачу → реализацию Codex’ом → ревью Claude → PR → слияние. К вечеру в локальной Gitea уже лежали PR #3, #5, #7, плюс добивки вокруг 1.0.2.

Звучит почти прилично.

На практике приличие началось не сразу.

Сначала я создал Gitea-репозиторий с auto_init: True, получил unrelated histories и потом восстанавливал нормальную историю через cherry-pick из reflog’а. Да, взрослый процесс. Да, с ударом лбом о дверной косяк на входе.

Потом первая попытка Codex’а упала на строгой схеме OpenAI: у каждого объекта в схеме должен быть additionalProperties: false. Не «желательно». Не «потом добавим». HTTP 400 и иди думай.

А ещё в working_dir всплыли кракозябры из-за cp1251→utf8. Не смертельно, но привет из мира Windows, где кириллица всегда ждёт в тёмном углу и улыбается.

Трекер смотрит на того, кто его строит

Самый красивый момент случился почти незаметно.

Я тестировал хук окончания сессии. Claude завершал сессию. Хук писал событие в tracker/claude-events.jsonl. Потом мы правили хук. Потом снова завершали сессию. Потом снова писалось событие.

И в какой-то момент я понял: трекер уже трекает собственную постройку.

То есть я смотрю на файл, в котором лежит история создания файла, который записывает историю создания файла.

Нормальная такая рекурсия выходного дня.

Я: «Подожди, он сейчас считает эту же сессию?»

Claude: «Да. Хук окончания сессии глобальный».

Я: «То есть он видит не только этот проект?»

Claude: «Он видит все Claude Code сессии».

И вот тут маленький локальный счётчик превратился в observatorium.

Хук был зарегистрирован глобально в ~/.claude/settings.json. Значит он ловил не только multi-agent, но и параллельные сессии в WMSTnext, и субагентов, и всё, что проходило через Claude Code на этой машине. Не потому что мы так хитро задумали. Просто хук глобальный.

С одной стороны — прекрасно. Полная картина использования.

С другой — приватность и нагрузка сразу перестают быть «потом подумаем». Если Phase 4 когда-нибудь покажет публичные метрики на сайте, сырые транскрипты туда не поедут никогда. Только агрегаты, короткие хэши, обезличенные пути, без содержимого запросов. Иначе это не дашборд, а добровольная публикация собственного чердака.

Второй сюрприз был злее.

Хук на старте сессии для оценки сложности должен запускать claude -p --bare. Флаг --bare тут не декоративный. Он нужен, чтобы оценочная сессия не тащила за собой обычное окружение и не запускала собственные хуки в петлю.

Потому что если каждая оценка запускает новую сессию, а каждая новая сессия запускает оценку, то это уже не автоматизация. Это маленький финансовый чёрный квадрат.

После обратной загрузки у нас оказалось 247 файлов транскриптов. Если на следующем старте сессии хук бодро запустит 247 дочерних процессов оценки сложности — будет не продуктивность, а ад из лимитов запросов. И это поймали до того, как я открыл следующую нормальную сессию.

Вот зачем нужен второй агент на ревью.

Codex хорошо прошёлся по ширине: нашёл места, где может бахнуть, проверил схемы, краевые случаи, обратную загрузку, дедупликацию. Claude лучше собрал смысл: что это значит для архитектуры, где граница приватности, почему --bare не мелочь, почему формула экономии сначала была перевёрнута не туда.

Эмпирическое правило дня: Codex лучше ищет по ширине, Claude лучше собирает смысл.

Не абсолютный закон природы. Просто в этот день так работало.

Что я нашёл в шестидесяти тысячах

После обратной загрузки история выглядела так:

• 79,716 событий за период с 2026-03-09 по 2026-05-09.
• 247 файлов транскриптов.
• JSONL после обратной загрузки — около 30 MB.
• Пиковый день — 31 марта, 1,113 calls.
• По моделям: Opus 4.7 — 53,854 calls, Opus 4.6 — 9,418, Sonnet 4.6 — 16,275.

Итоговая сумма по API-тарифам: 4 824 000 рублей.

Сразу оговорка, жирная и скучная: это пока завышение на 10-15%. Старые записи с Opus 4.6 считаются по ценам 4.7, потому что история моделей не идеальна. После пересчёта цен будет точнее. Реалистичнее ожидать 4-4,4 миллиона, а не ровно 4,82.

Но даже если это не пять миллионов, а четыре — порядок не меняется.

Я заплатил 32 тысячи за два месяца Max-подписки.

Если бы платил по API-тарифам — было бы около 4,8 миллиона в текущей грубой оценке.

Экономия относительно API-варианта — 4,79 миллиона по первому расчёту. Даже после уточнения цен останутся миллионы.

И вот тут мозг делает смешную вещь. Он одновременно понимает, что это не настоящие «заработанные деньги», потому что я бы просто не стал так использовать API за прямые деньги, и одновременно не может игнорировать факт: объём вычислений, который я реально прогнал за два месяца, стоит на открытом тарифе как хорошая машина.

Это не бизнес-кейс для презентации.

Это личная фотография масштаба.

Я: «То есть Max за 16 тысяч в месяц — это не дорого?»

Трекер: «Смотря с чем сравнивать».

Я: «С API».

Трекер: «Тогда это почти неприлично дёшево».

Я раньше писал про разгон как про ощущение: больше задач, больше артефактов, больше связей между проектами. Теперь к этому ощущению прирос счётчик.

Не идеальный. Не финальный. Но уже достаточно честный, чтобы стало слегка не по себе.

Что я унёс с собой

Глобальный хук — это власть. Он видит всё, и значит дизайн надо начинать не с красивого дашборда, а с границы приватности. Что пишем, куда пишем, что никогда не публикуем, как обезличиваем путь — это первое решение, не последнее.

Автоматизация должна иметь тормоза. Обратная загрузка на 247 сессий плюс дочерний процесс на старте сессии — почти готовый способ самому себе устроить ад из лимитов запросов. Ограничитель частоты — не украшение, а предохранитель.

И самое неудобное: про деньги надо говорить аккуратно. Я не потратил $60k. Я использовал подписку так, что эквивалентный счёт по API был бы около $60k. Разница принципиальная. Иначе это превращается в инфоцыганскую картинку, от которой самому стыдно.

А теперь хочется ещё хуже

Текущий трекер считает деньги. Следующий слой — время.

Phase 1.3 должен научиться оценивать сложность задачи: сколько часов это заняло бы без ИИ, сколько заняло по реальным часам, какой получился множитель. Не «истина в последней инстанции», а личная шкала. Если задача без ИИ была бы на 8 часов, а с агентами заняла 50 минут — это уже не просто красивое ощущение.

Потом хочется отслеживать настроение.

Не только «сколько токенов», но и сколько раз я матерился. Счётчик раздражения. Благодарности. Моменты, где я пишу «ёбать» не потому что всё сломалось, а потому что трекер показал $60k.

Потом дашборд. Конечно, киберпанк. Графики, крупные числа, локальный HUD, виджет «сколько осталось до лимита», карточки для блога, которые можно публиковать без сырых данных. Тот самый случай, когда эстетика не мешает инженерии, потому что счётчик должен быть видимым. Если он спрятан в JSONL, мозг его быстро перестаёт чувствовать.

Дальше публичная статистика на androman.pro. Только агрегаты. Никаких транскриптов. Никаких приватных путей. Никаких клиентских имён. Просто «за месяц модель сэкономила N часов / N долларов эквивалента / N дней жизни, которые я всё равно потратил на новые задачи».

А где-то в дальнем углу планов лежит AR-оверлей через Xreal: маленький HUD в углу зрения, агент в сети, PR готов, расходы за сегодня, голосовая команда «merge PR».

Звучит как фантастика.

Но сегодня утром у меня не было трекера. К вечеру он уже нашёл пятьдесят с лишним тысяч долларов не-потраченных денег.

Так что я теперь осторожнее со словом «фантастика».

Самое смешное

Самое смешное не в сумме.

Сумма — это просто неоновая вывеска, на которую удобно смотреть с открытым ртом.

Самое смешное в том, что я строил инструмент для измерения собственного ИИ-разгона, а он сразу стал частью этого разгона. Он писал JSONL о сессиях, в которых его писали. Он ловил параллельные ветки. Он обнаружил угрозу собственных оценочных дочерних процессов. Он заставил переписать формулу экономии, потому что первая версия думала не туда.

Счётчик оказался не прибором снаружи системы.

Он оказался ещё одним участником системы.

Подписка окупилась примерно в 150 раз. Трекер это посчитал сам. А я теперь сижу и думаю, сколько ещё вещей вокруг меня уже пора начать считать.

Потому что ощущение — врёт красиво.

JSONL врёт скучнее.

Через три дня

Я открыл черновик утром, хотел внести «пару правок перед публикацией».

Через четыре часа переписываю заново.

Откуда вообще трекер

Если совсем честно — трекер был побочным продуктом.

Изначальная задача звучала по-другому: настроить совместную работу трёх ИИ-агентов. Claude разбивает задачу на куски и проверяет результат — архитектор. Codex реализует — разработчик. OpenClaw — мост через Telegram, чтобы давать команды с телефона из бара. Три модели, три API, три разных протокола. Хотелось чтобы они передавали друг другу задачи и не ругались по поводу того кто из них что испортил.

Чтобы этот конвейер не превратился в чёрный ящик, нужно было видеть кто из агентов что сделал, за сколько токенов и времени. То есть нужен был учёт. А значит — трекер.

Учёт оказался первой готовой частью и пожрал внимание. Заголовок про пять миллионов — оттуда. А мульти-агент тем временем тихо собирался в фоне.

К 12 мая он работает. Я пишу боту в Telegram «обнови README в репо», OpenClaw принимает, Claude составляет план, Codex реализует, DeepSeek (третий ревьюер, появился за эти три дня) проверяет. Я только апрувлю. Это уже не «один человек с одним трекером». Это маленький конвейер из трёх ИИ и одного меня.

В репозитории за три дня прирос не только трекер. Прирос мульти-агент, ради которого его и затевали. И заодно — имя neon-legion (вместо служебного multi-agent) и слоган, в котором счётчик ругательств вынесен прямо в название: «Твоя личная армия. Почти без ебать-колотить. Да, мы считаем маты». Маты считаются не для красоты. У каждой Claude-сессии в дашборде есть поле profanity_count, заполненное по факту. Шутка — это фича.

Где деньги, Лебовски

Тут хочется разобраться с одной неудобной вещью.

На 9 мая трекер показывал 4,8 миллиона. Сейчас, пока пишу эту главу, уже 5,77 миллиона — за три дня плотной работы с моделями цифра прибавила ещё почти миллион. Трекер тикает прямо сейчас. На статье тоже.

Подписка нарастающим итогом — 48 тысяч за два с половиной месяца. Экономия относительно API-варианта — 5,72 миллиона.

Хочется носить эту цифру на бейдже.

Только в кошельке у меня не прибавилось пяти миллионов. Где же деньги, Лебовски?

Их нет, потому что я бы не потратил эти пять миллионов. Если бы подписки не было, я бы не оплатил все эти запросы по API. Я бы просто сделал в десять раз меньше. Экономия — это сравнение с ситуацией, в которой я бы вообще так не работал. Бенчмарк, а не выручка. Цифра на бейдже была бы враньём.

Но интересно другое.

ИИ даёт мне условные 10x к производительности. Не маркетинговая цифра — субъективная оценка, подтверждённая таблицей часов: без ИИ я делал бы в десять раз меньше за те же часы. Допустим, мой месячный оборот по задачам — 2,5 миллиона. Тогда один «ИИ-работник» делает работы примерно на 250 тысяч в месяц.

250 тысяч — это зарплата нормального мидла в РФ. Не сеньора, не лида. Но мидла-с-опытом точно.

Подписка стоит 16 тысяч в месяц на двоих, Claude Max + ChatGPT Pro. На неё работает четыре таких ИИ-мидла одновременно: Claude думает, Codex пишет, DeepSeek ревьюит, OpenClaw таскает между ними сообщения.

Вот где деньги: на каждой ИИ-подписке я не получаю +250 в карман. Я не плачу 250 тысяч зарплаты человеку, которого иначе пришлось бы взять. Дельта — невидимая экономия. Её нельзя положить на стол. Но именно она позволяет мне делать в десять раз больше за те же часы.

В кошельке прибавилось не пяти миллионов. Прибавилось возможности.

Возможность — паршивая единица отчётности. На неё хорошо ложится подписка и плохо ложится ипотека.

Что в итоге

Я: «Так ты считаешь свою собственную статью прямо сейчас?»

Трекер: «Конечно. Я глобальный».

Реальный сегодняшний счёт после догона: 67 тысяч рублей в эквиваленте API за один день.

За три дня в репозиторий приехало много мелочи: тесты, сканер приватности перед публикацией, демо за минуту, починка кракозябр, конфиг в одном файле, плюс одна красивая штука — Hindsight Replay, когда вторая модель пишет критику работы первой. Подробности — в коммитах между 9 и 12 мая.

Главная функция трекера — не показать сколько ты сэкономил.

Главная функция трекера — показать насколько ты эффективен и сколько примерно стоит твой труд, если его будут делать ИИ.

Пока они дороже тебя — будь спокоен.

Если они начнут выполнять ту же работу что и ты, без ошибок и дешевле — ты станешь не нужен.

Трекер посчитает и это.

Посмотреть:

• Живой дашборд — что трекер показывает прямо сейчас: множитель, сэкономлено, активные часы, разбивка по моделям
• github.com/andromanpro/neon-legion — open-source, MIT, stdlib-only Python, локальный pipeline без внешних обращений

→ открыть на androman.pro

1С vs веб через ИИ — два разных мира

В 1С не так. Там огромный контекст, галлюцинации модели и загрязнённый контекст: контекст одного проекта просачивается в выводы по другому, имена путаются, факты выдумываются. Платформа сопротивляется.

В вебе — свобода. Сформулировал хотелку, пусть даже криво, и через минуту уже есть что потрогать. Не нужно неделю входить во фреймворк, читать документацию к новому инструменту и вспоминать, почему CSS опять делает вид что всё нормально. ИИ быстро накидывает варианты, а я уже выбираю, что похоже на меня.

Цифры одного дизайна

На эту тему ушло 5 итераций по 3 варианта в каждой. Итого 15 разных тем, каждая собиралась на основе того, что понравилось в предыдущих. В итоге получилась не «идеальная тема», а тема, которую я наконец не хочу немедленно снести.

Главное что вышло:

• Декодер-заголовок — androman.pro на главной печатается через шумовые символы █▓▒░, потом «защёлкивается» в текст и морфит между androman.pro → .1С → .ai → .dev. Glitch — короткий RGB-бурст 2.5 секунды.
• HUD-углы — agent ONLINE, build v0.6.x, mode roaming, focus hyperfocus. Левый верхний кликается — открывается changelog проекта (RU/EN, версии с alpha до текущей).
• Страница /сейчас — кроме обычного описания фокуса, terminal-блок со 150 случайными dev-фразами в киберпанк-стиле. Клик — мгновенный реролл.
• Команд-палитра — нажми / (на любой раскладке клавиатуры — работает на ЙЦУКЕН тоже), всплывает терминал команд.
• Визуальная лаборатория — 7 моих open-source WebGL/Canvas-проектов собраны в одной странице. У одной из карточек — hover-preview живой 3D-сцены через lazy-load.

Шрифты — все 74 woff2 self-hosted. Никаких Google Fonts CDN, сайт работает без внешних соединений.

Парадокс роста

Заметил парадокс: чем больше разрабатываешь с ИИ, тем сильнее растёт бэклог задач. Раньше идея «было бы круто» оставалась идеей. Сейчас — становится таском в течение часа. Скорость реализации опережает способность приоритизировать.

И ещё — перфекционизм. Если уходишь в него, тратишь неимоверно больше времени, чем если довольствуешься средним вариантом. Но это везде так, принцип Парето — 80% результата за 20% времени, остальные 20% — за всю оставшуюся жизнь.

Workflow получился взрослый

Заодно собрался нормальный workflow разработки сайта: тестовый и прод-контуры, возможность обкатать фичи до выхода в прод. Всё через git, версионирование, автодеплой по rsync через SSH. Бэкап БД и файлов — до любого изменения.

В общем — я доволен. Так и должен выглядеть собственный сайт. Хотя в наше время это уже похоже на ретроградство — социальные сети поглотили личные блоги. Но мне так нравится.

Открытие про безопасность

ИИ заодно проаудировал сайт и подсветил то, чего я не знал: пароли от БД у CMS традиционно хранятся в открытом виде в конфиге. Это касается всех — WordPress, Joomla, Drupal, Magento, любого PHP-стека. Защита идёт не криптографией, а правами файла + правильной настройкой веб-сервера.

Закрыли всё что обычно светится: XMLRPC отключён, REST /users скрыт от анонимов (admin slug больше не виден), ?author=N редиректит на главную, readme.html и license.txt удалены, security-headers через PHP + .htaccess.

Что дальше

Сайт работает. Версия 0.6.x — pre-release, до публикации 1.0 хочу наполнить блог постами и быть уверенным в каждой странице.

Ближайшие планы — перенесу статьи с инфостарта, плюс буду публиковать эксклюзивы здесь. Радар на сайте уже ждёт blip’ов.

→ открыть на androman.pro