С другой стороны это похоже на ещё одну игру в жанре «ИТ-стратегия», которую я так хочу пройти. Не знаю, какие уровни будут дальше, но вчера я, похоже, взял ещё один уровень. Наконец-то разобрался с одним из элементов 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

147 часов активного общения с моделью. Тридцать активных дней из тридцати — каждый день апреля без пропусков. В среднем — около пяти часов в день, включая выходные.

И что самое удивительное — я не выгорел. То есть такой ритм и такая форма работы — это прям как подошедший пазл в мою СДВГ-шную голову. Раньше у меня была куча идей, они перерастали в планы, но быстро затухали, оставшись лежать либо забытым черновиком на задворках папок компьютера, либо неработающим приложением, когда столкнулся с проблемой, превышающей собственную компетенцию. Игра перевернулась с появлением ИИ — теперь от задумки до первого прототипа иногда проходит меньше 10 минут, и это обескураживает и пугает одновременно. Но что могу сказать точно — это увлекает так, как ничто другое не увлекало уже много лет.

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

Это не усталость. Это разгон.

Что получилось за месяц

Продуктовый аудит крупной WMS-конфигурации под сертификацию «1С:Совместимо» — мой большой клиентский проект апреля. Два этапа поставки, около 185 источников в md по этапам аудита, восемь итоговых документов для четырёх типов руководителей (техдиректор, гендиректор, финдиректор, инвестор — у каждого свой угол), архитектурный разбор регистров, обзор безопасности, дорожная карта на 6-9 месяцев, финансовая модель и сравнение с шестью конкурентами по WMS. К концу месяца — комплект документов на ~400 страниц. В общем работа целого отдела разных специальностей на протяжении нескольких месяцев.

Свои pet-проекты — про них уже отдельный пост. Если коротко: 76 коммитов в ai-conversation-viz, выпуск пакета @andromanpro/lava-orb v0.1.1 на npm, две новых браузерных игрушки (orb-2048, orb-arkanoid), редактор частиц fire-particle-editor, генератор печатных кроссвордов. Большинство под лицензией MIT, на GitHub.

Свой блог androman.pro. Перезапустил на собственной теме для WordPress (15 итераций дизайна, см. «Я это сделал!»), опубликовал два поста за апрель. Раньше я не выкладывал ничего по 6 лет — теперь у меня в черновиках ещё восемь штук статей, включая этот. И проекты растут гораздо быстрее статей!

Я ненавижу инфоцыган, но на работе попросили рассказать про мой опыт использования ИИ. Оттуда выросло несколько статей, учебный курс, презентации и книга. Все в неотшлифованном виде, так что публиковать рано. Тем более каждый день я туда дописываю по кусочку и выстраиваю свой идеальный воркфлоу.

Курсы и книга. Курс К01 «ИИ-Аудит 1С» — пять модулей по реализму процесса аудита плюс одиннадцать модулей самой механики. Курс К02 «ИИ-Разработка 1С» — структура и материалы (EDT, CodePilot1C, YAXUnit, SonarQube, GitSync). Книга «ИИ-аудит конфигураций 1С: полное руководство» по материалам К01 — две главы готовы, ещё несколько начаты, скрипт-сборщик в работе.

Клиентские 1С-проекты — четыре активных направления. Техаудит большой 1С-системы с миграцией учёта (рекомендация архитектуры по результатам интервью с ИТ-командой сменилась с одной системы на три раздельные). Обновление складской системы у вендора с разбором обработчиков шинной интеграции и состоянием гонки в одном из обработчиков перемещения. Интеграция ЭТрН в УПП у производственного предприятия. Правки внешних форм для медицинской 1С. Без имён — это NDA-зона.

Серия «Деформации ИИ» — семь черновиков о собственных граблях с моделью за апрель. Про синтетическую карту интеграций (контекстное заражение между проектами через общую папку), про самосохраняющиеся ошибки через ссылки, про инцидент со стиранием 100 файлов баз из-за уверенности в симметрии кодировок cp1251utf-8. Серия пишется как памятка-инструкция, не как обвинение модели — этим инструментом надо уметь пользоваться, и ошибки бывают и без него.

ИИкона — мой pet-проект платформы ИИ-персонажа для контакт-центров. В апреле — исследование, диаграммы, описания API. Сам продукт ещё в подготовке, но коннектор уже на гитхабе — у него больше 50 звёзд. ИИ говорит, что мама бы мной гордилась). Только я понимаю, что он требует развития, но пока не могу к нему подобраться из за продуктивной прокрастинации.

Инфраструктура (мини). SonarQube + BSL Plugin v1.17.2 запущены на NAS, форк CodePilot1C обновлён, openclaw перезапущен через NAS-ветку, удалённое управление Claude с телефона работает, скилл cyrillic-paths написан после двух инцидентов с кодировкой, скилл androman-writing-style собран после двух итераций самоанализа собственных текстов. Пара десятков мелких улучшений вокруг.

Цифры месяца

В сумме за апрель получилось:

• ~80 значимых сессий Claude Code (плюс пара сотен мелких автозадач — синтез заметок, обновление памяти, плановые скрипты; их в подсчёт человеческого времени не включаю)
• 147 часов активного общения с моделью по правилу <2 минут между сообщениями. Сначала посчитал по сессиям, получилось 169 — но это включает многозадачность (когда работают одновременно десктоп и удалённая сессия с телефона). После объединения по единому таймлайну осталось 147 — это реальное физическое время. Двадцать часов разницы — артефакт параллельной работы.
• Пик активности — 28 апреля, 9 часов (день публикации предыдущего поста)
• ~300 МБ исходников в md / docx / pptx нового содержания
• ~40 000 строк кода в pet-проектах (из прошлого поста)
• ~50-60 значимых артефактов — документ / диаграмма / модуль / скилл / пост
• ~150-200 модулей правленых в 1С-проектах
• 2 публикации на блоге + 7 черновиков «Деформаций» — уже больше

Распределение часов по линиям (после нормализации на 147):

Если бы делал то же самое без модели — приблизительная личная оценка по типам задач:

Грубая прикидка — ~2640 часов руками против 147 с моделью. Звучит как полтора года в полный рабочий день против одного апреля, и именно поэтому к этой цифре надо относиться осторожно. Не как к бизнес-метрике, а как к личному дневниковому масштабу: где-то модель правда срезала месяцы входа в незнакомую область, а где-то просто сидела рядом, пока я глазами проверял результат.

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

Где модель съела больше времени, чем сэкономила

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

Контекстное заражение через общую папку. В корне рабочей директории лежал CLAUDE.md одного проекта. Модель прочитала его как «общий контекст», и в выводы по другому проекту просочились имена, факты, отрасли. Я обнаружил это через несколько сессий — артефакты пришлось откатывать, проверять перекрёстными ссылками, переписывать. Стоимость — пара дней разбора. Без модели я бы такой ошибки не сделал, потому что не было бы общей папки.

Восемь выдуманных методов БСП в одной поставке. Модуль уверенно ссылался на СтрокаЯвляетсяЧислом, ОбщегоНазначения.ТекущаяОрганизация и так далее — методов, которых в БСП не существует. Поймал ручной проверкой по ИТС в самом конце цикла, перед сдачей. Стоимость — половина смены на проверку и переписывание шести публичных файлов. Без модели — методов было бы меньше, но и существовали бы они все.

Состояние гонки в обработчике перемещения. Модель сама же дважды переписала код «по-старому», после чего сама же выявила состояние гонки в собственном свежем коде. Колесо. Я три раза сидел и убеждал её, что именно это место она же ломала час назад.

Стирание 100 файлов баз. Уверенность модели в том, что cp1251utf-8 симметрично. Не симметрично оказалось. Слетели имена баз — я думал что не имена, а сами базы, и обнаружил это в холодном поту. Восстановил из бэкапа за полчаса. Без бэкапа было бы драматичнее.

Категоричные архитектурные утверждения. Четыре регрессии за одну сессию: «не подходит вообще», «обязательно нарушает стандарт», «100% / всегда / никогда» — без ссылки на ИТС, без открытых источников. Поймал сам через самопроверку. После этого сделал отдельный скилл, который заставляет модель отделять факты от компромиссов.

«Сам написал — сам забыл». Создал скилл с правилом, в этой же сессии его нарушил. Скилл указывал — для сессий в EDT-проекте сначала использовать семантические индексы (edt-mcp / Serena), а не Read/Grep. ИИ сделал скилл, и через двадцать минут полез искать по *.bsl руками. Скилл сработал бы — если бы ИИ не забыл его прочитать.

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

ИИ как лошадь — везёт быстро. Но если не держать поводья, увезёт в овраг и сам же удивится, как мы сюда попали.

Главное открытие: разгон

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

Получается так:

• Барьер входа в новую область упал. Я зашёл в WebGL2 не зная что такое display:flex. В графовую визуализацию — без знаний D3. В книгу — никогда не писал книг. В разбор чужих кодовых баз через семантические индексы — раньше это была работа на месяц чтобы только настроить инструменты. Теперь — на полчаса.
• Стоимость прототипа околонулевая. Идея → черновик → проверка реальности занимает один вечер. Большинство идей умирают на этапе черновика, и это нормально. Раньше до этой точки — недели.
• Каждый закрытый проект порождает соседей. Большой WMS-аудит породил скилл 1c-product-audit-discovery. Тот породил методологию для других аудитов. Та породила пост на блог. Тот породил идею книги. Та породила курс. Курс породил материалы для следующего курса. Все эти артефакты реально стоят отдельно, у каждого своя ценность.
• Соединения между областями работают. Pet-проект ai-conversation-viz — визуализация диалогов с моделью, и она оказалась полезной для аудита. Работа с клиентами породила методологию, методология стала книгой, книга породила скилл androman-writing-style. Всё взаимосвязано и работает как единый организм — по кирпичикам или частицам пазла. Как в факторио или сфера Дайсона (это игрушки, которые забрали много моего времени — я прям залипал)

В предыдущем посте я сформулировал тот же паттерн как проблему: «Скорость реализации опережает способность приоритизировать». Через несколько дней я понимаю — это не проблема. Это и есть продукт.

Бэклог — это не «то, что не сделано». Это пространство возможного, и оно расширяется. Если сжать его обратно — потеряешь ровно то, ради чего всё начато. Можно ныть про 30 невыполненных задач, можно жить в реальности, где их 30 живых, и каждая интересна.

Маховик. Раз набрал скорость — несёт. Тормозить можно, но зачем. Главное чтобы он вынес в правильное русло.

Что дальше

Май — финал крупного WMS-аудита, начало 6-месячного забега до сертификата «1С:Совместимо». Книга — следующие главы. Серия «Деформации ИИ» — часть черновиков перейдёт сюда отдельными постами, рабочее название «инструкция по эксплуатации модели».

Но есть тема, о которой неудобно молчать. У меня хроническая проблема — закрывать проекты. СДВГ хорош для разгона: гиперфокус в окне интереса даёт ровно те пять часов в день, которые я насчитал в логах. Но за окном интереса — оставляет хвост. На каждый закрытый проект — два-три открытых, и не все из них доходят до релиза.

Хвост на май:

• ИИкона — доработать. Накопились запросы пользователей, да я и сам понимаю чего ей не хватает.
• Расширение для 1С по генерации диаграмм через ИИ — закончить плагин и выпустить статью.
• Личный астролог — обработка + статья. Эзотерика + ИИ = чистое искусство перфоманса. Жалко только что кто-то воспримет всерьёз.
• ИИкзаменатор — учебная платформа на базе ИИконы для автоматического создания и прохождения тестов.
• make-it-zbs — волшебная кнопка для компа. Одной командой улучшить всё что можно. Идея крутая, надо доводить.

Когда хвост закроется — если закроется — приступать к собственным коммерческим продуктам. Помощник по саду и огороду: куда что посажено, когда поливать, что обрезать, интернет вещей в перспективе. Шелл Апокалипсиса — личные коллекции топов медиа: «сто лучших фильмов / книг / игр / альбомов» в одном месте, локально без интернета.

Маховик и так крутится. Получится ли не отрастить новый хвост, пока закрываю старый — отдельный вопрос.

Поживём — увидим. Пока мне это нравится, а значит сам путь приносит удовольствие, а не конец пути. В общем я на пути к дзену!)

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

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

Но дело не в этом.

Посмотрел я, с какой скоростью с ИИ получится сделать опросник. Добавил тёмную тему на выбор, контроль неотвеченных вопросов, даже салют при завершении. Всё, можно закрывать.

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

Тут-то всё и заверте…

Наступили выходные, а ощущение незавершённости не отпускало. Обычный ползунок от 1 до 10 — это же просто цифра, не показательно.

Пришлось развивать — прототип, другой, третий. Покрутил настройки частиц. Узнал что есть Canvas 2D и WebGL 2 (ну как узнал — просто что они существуют). Добавил DOOM-fire (прям как из культовой игры, ну вы поняли) режим как альтернативный движок пламени. Попробовал сделать взрывы, физику воды, отрывающиеся от ползунка орбы, которые улетают по дуге.

Задача была в том числе — проверить, получится ли через ИИ сделать что-то в незнакомой области. Без глубокого погружения в шейдеры и прочие термины которые я впервые увидел на прошлой неделе.

Получилось.

Я думал — сделаю пару эффектов на ползунок и пойду обратно к опроснику.

Что выросло за 5 недель параллельной работы:

• npm-библиотека @andromanpro/lava-orb — привязывается к любому <input type="range"> одной строкой. От мороза до огня, взрывов и молний.
• 2 одностраничные игры — ORB 2048 (жидкие сливающиеся сферы с процедурной музыкой) и ORB ARKANOID (арканоид где блоки — орбы с физикой волн). Оба работают офлайн одним HTML-файлом.
• 2 интерактивных редактора — для тонкой настройки жидкости и огня в реальном времени. С экспортом пресетов.
• Библиотека из 7 WebGL2-фонов — drop-in для любой страницы.

Всё это — MIT, на GitHub.

Ни одного профильного курса по веб-разработке я не проходил. Я вообще не знаю, что такое box-sizing и display: flex)))

Помните 2048? Ту простую головоломку с плитками, которая в 2014-м разошлась по всем сторам за несколько недель. Сделал свою версию — с жидкими светящимися сферами вместо цифровых плиток. И залип.

Геймплей:
— Классическая сетка 4×4, свайпы / стрелки / WASD
— Ячейки — жидкие metaballs через marching squares, сливаются как капли ртути
— На высоких значениях — процедурный огонь частицами с glow и затуханием
— При 2048 — supernova: space warp, chromatic aberration, 250 частиц, тряска камеры
— Игра продолжается — 4096, 8192, логотип подхватывает

Звук:
8 процедурных треков через Web Audio API, никаких mp3. Oscillator + filter + reverb синтезируются в браузере. Адаптивный темп — чем больше ячеек, тем быстрее.

Рендеринг:
WebGL2 с Canvas2D fallback. 4 фона на выбор (Cyberpunk / Space / Dark / Synthwave). RU/EN локализация.

Бот / Autoplay — запускаешь, смотришь как играет сам. Максимум набирает 65 536 (16 слияний — дальше на сетке 4×4 места нет, но есть настройка для большей сетки!).

Для СДВГ-шников — идеальная сенсорная подкормка. Запускаешь на втором мониторе или в углу экрана, свернул — периферическое зрение ловит постоянное мельтешение жидких сфер, мозгу хорошо, на основной задаче сидишь ровнее.

Режим отладки оставил прямо в сборке — FPS, хитбоксы, статистика. Не стал прятать от прода, пусть смотрит кто хочет.

Один файл Orb-2048.html ~330 KB. Скачал на телефон в самолёт — играешь офлайн.

ЗАПУСТИТЬ ORB 2048

Live: andromanpro.github.io/orb-2048

Если 2048 — про «плавное слияние», то арканоид — про «разрушение». Идея: блоки — это не кубики, а светящиеся орбы-капсулы с жидкостью. Она реагирует на удар волной, а при разрушении выливается вниз, передавая волну соседям.

Так и сделал.

Геймплей:
— 15 уровней, каждый со своей темой, музыкой и фоном
— 9 типов орбов — Fire, Ice, Water, Earth, Lava, Steel, Gold, TNT, Rainbow (у каждого своя физика и звук удара)
— 8 power-up — расширение/сужение платформы, огненный шар, мультишар, прилипание, лазерные турели, жизнь, замедление времени
— Комбо-система и локальная таблица рекордов

Технологии:
— WebGL2 SDF-шейдер для орбов — круглый SDF, 2 слоя жидкости с Catmull-Rom интерполяцией, спекулярный блик
— Verlet 6-колоночная пружинная симуляция волн
— Процедурная музыка на каждый уровень

Тюнинг шарика:
Тип хвоста (FIRE / LAVA / PLASMA / ICE), длина S/M/L, размер S/M/L. Превью шарика в настройках — живая анимация на весь экран, клик для запуска.

Бот со скоростью ×2.5. Прицеливается в конкретные орбы, проходит уровни сам. Можно включить и бесконечный режим — уровни продолжают генерироваться сверх 15 штук, бот разбивает бесконечно. Играет лучше меня.

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

Режим отладки тоже оставил в сборке — FPS, хитбоксы, прыжки между уровнями через [ и ]. Dev-инструменты не прятал.

97 unit-тестов встроенных в game.js. Я сам не представлял, что в браузерной игре буду их писать. Но если разрабатывать с ИИ — приходится проверять каждый шаг.

Один файл ~225 KB, работает офлайн.

ЗАПУСТИТЬ ORB ARKANOID

Live: andromanpro.github.io/orb-arkanoid

Важный юридический момент. Arkanoid — зарегистрированная торговая марка Taito с 1986 года (легендарная японская компания, сейчас в составе Square Enix). Моя игра называется ORB ARKANOID чисто как дань уважения жанру — пока это open-source прикол, никто не придёт.

Но если я начну рубить с этого капусту — Taito быстро найдёт меня через юристов. Код можно форкать (MIT разрешает), но имя «Arkanoid» — не моё чтобы его дарить. Для коммерческого форка придётся переименовать в что-то нейтральное вроде ORB BREAKOUT (слово «breakout» — общий жанр, не товарный знак), поменять логотип — и тогда можно идти в сторы.

Это к вопросу «а можно я возьму и продам» — в принципе можно, но с переименованием.

Решил посчитать — сколько я реально на это потратил.

Прошёлся по логам сессий Claude Code — там у каждого сообщения timestamp. Если между сообщениями меньше 2 минут — это активная работа. Больше 2 минут — отошёл или задумался без ИИ.

Итог: 41 час активного общения. На 7 артефактов, 40 981 строку кода.

Для сравнения, 1С-разработчику без веб-опыта (это я) без ИИ на это ушло бы:
— 3 месяца на изучение стека (HTML / CSS / JS / Canvas2D / WebGL2 / WebAudio)
— Ещё ~6 месяцев на реализацию

Грубая оценка — около 8 месяцев full-time вместо 5 недель коротких периодических сессий. Не научная цифра, просто мой внутренний «сколько бы я на это убил, если бы шёл один».

Ускорение не в «ИИ пишет код за тебя». Оно в том, что ИИ убирает барьер незнания. Можешь формулировать задачу словами и сразу получать рабочий прототип — вместо того чтобы тонуть в документации к шейдерам, которая предполагает, что ты уже знаешь что такое SDF, metaballs и Verlet integration.

Для меня это самая сильная зона ИИ: незнакомые специализированные домены, где сначала нужно месяцами накапливать словарь, а только потом начинать делать.

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