Автономный конвейер дня

Один день конец-в-конец, чтобы было видно стыки.

• Вечер. Антон говорит кодовое слово в проекте конвейера. Сессия обсуждает состав завтрашнего дня, расставляет приоритет линий и кладёт очередь в демон. Сессию можно закрывать — очередь живёт на диске.
• Ночь. Демон держит несколько слотов сразу — разные проекты идут параллельно, одна линия на проект. Каждую запускает по одному шагу за раз в изолированной копии. Линия работает черновиком, упирается в развилки, каждую записывает в журнал. Вопросы копятся — в Кэтчер ночью не уходит ничего. Между шагами демон смотрит на остаток окна: не влезает — линия ждёт на чекпоинте, влезает — идёт дальше.
• Утро. Судья прочёсывает журналы всех линий: сверяет с диффом, проверяет, что в память ходили, дедуплицирует и отбирает то, что правда требует Антона. Работает он всю ночь по мере готовности шагов, а не пачкой в 8 утра: возвраты «схалтурил, доработай» переигрываются ночью. К утру перечень заморожен и состоит только из провалидированных вопросов — Антон никогда не ждёт доработки. Страница с блоками по проектам, варианты на кнопках, свёрнутый список «решил по умолчанию».
• День. Ответы уходят линиям, работа продолжается с той же точки — та же сессия через --resume, ничего не переделывается. Новые развилки решаются по дефолту; в Кэтчер прилетает только необратимое и дорогое.
• Готово. Линия проходит гейт: регрессия целиком, чек-лист проекта, клики браузером, хуки. Не прошла — линия не завершена: получает шаг «починить» и идёт на второй круг сама, без человека. Прошла — сливает в main, деплоит, пишет отчёт в задачу ПланФикса и шлёт в Кэтчер «готово, можно принимать». Слот освобождается, демон берёт следующую линию из очереди.
• Приёмка. Антон садится, когда есть время, смотрит журнал, жмёт «Принял» — ветка и рабочая копия удаляются — или «Есть замечания» и пишет текст: он привязан к id линии, уходит в очередь демона и приходит в ту же сессию через --resume новым шагом. Приёмка ничего не блокирует — слот давно освобождён, остальные линии работают.

Один агент на всё — неправильно: тот, кто писал код, плохой проверяющий собственного кода. Линия это цепочка ролей, каждая своим субагентом.

• Постановщик — режет работу на шаги, формулирует критерий готовности.
• Исполнитель — пишет код; запускает своих субагентов, чтобы не пух контекст (переполненный контекст = ошибки).
• Ревьюер — не тот, кто писал. Проверяет код по существу.
• Тестировщик — регрессия и сценарии в браузере, отдельно от ревьюера.
• Судья — стоит над всеми, отвечает только за вопросы к Антону.

Строить с нуля не надо: в проекте уже есть code-reviewer, test-reviewer, qa-checker, skeptic, reality-checker. Задача — собрать их в цепочку линии.

Три уровня строгости — полная цепочка нужна не всем

• Лёгкий — исполнитель + тесты + клики. Правка текста, конфиг, мелкий фикс.
• Средний — плюс ревьюер. Обычная доработка кода.
• Полный — плюс скептик. Новая фича, боевые данные, деньги, внешние интеграции.

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

Кто проверит, что уровень выбран верно

• Механически, не мнением. Тронуты боевые данные, миграции, деньги → полный уровень назначается автоматически из диффа, постановщика не спрашивают. Есть изменения в интерфейсе → клики обязательны.
• Судьёй. Выбор уровня — такая же развилка, как любая другая: пишется в журнал с обоснованием и проверяется наравне с остальными. Судья вправе поднять уровень, понизить — нет.

Задач по Телеграму много, без способа «зайти и проверить» линия их не закроет.

• Мини-эпп — обычная веб-страница, Телеграм для неё только оболочка. Playwright открывает по URL и кликает как любой сайт. Работает уже сейчас.
• Бот и его кнопки — программный Telegram-клиент на отдельном тестовом аккаунте: пишет боту, читает ответы, жмёт inline-кнопки, проверяет реакцию. Полноценная эмуляция человека, а не подделка через Bot API. Библиотека — Pyrogram, как в Аутриче: вторую в воркспейс не тащим.
• Боевого бота не трогаем — проверка на тестовом.

✅ Номер под тестовый аккаунт есть — из проекта Аутрич (Антон, 2026-08-19).
⛔ Сломать Аутрич нельзя: берём свободный номер, а не задействованный в рабочих сценариях · файлы сессий и конфиги Аутрича не трогаем вообще, своя папка и свои креды · перед реализацией читаем его код, а не действуем по аналогии.
Telegram Web через Playwright рассматривался и отклонён: сессия протухает и требует ручного кода, для автономной работы негодно.

Линия — последовательность шагов, а не один бесконечный запуск

Отсюда берётся весь контроль. Один запуск = один шаг, между шагами линия отчитывается чекпоинтом, и демон решает, пускать ли дальше. Демону не нужно уметь прерывать работающую сессию — он просто не начинает следующий шаг. Проще и надёжнее.

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

Состояния линии

Автономное решение проблем

Оркестратор должен уметь то, что сделал бы Антон за компом — не встать, а придумать, как продолжить. Честная граница: качеством суждения это полностью не гарантируется. Кодом даётся:

• Каталог типовых тупиков: упал чужой тест → обойти и завести задачу; отвалился внешний API → повтор, затем пауза, не падение; конфликт с чужой незакоммиченной работой → стоп по проекту.
• Право откатиться и пойти обходом вместо остановки.
• Право переключиться на другую линию вместо простоя.
• Запись «здесь решил сам, вот чем» в журнал — по ней каталог пополняется от прогона к прогону.

Поправка: мы на подписке, а не на API. Стоимость из вывода запуска — не деньги и не счёт, а прокси-метрика расхода. Годится как относительный измеритель «эта фаза тяжелее той», но не как бюджет. Реальные лимиты подписки — 5-часовое окно и недельный потолок, в долларах они не выражены.

• Считает демон, не сессия. Он не знает «сколько осталось» — этого никто не знает. Знает два числа: потрачено за окно (сумма всех завершённых запусков за 5 часов) и сколько стоит шаг такого типа по накопленной статистике. Правило пуска: потрачено + оценки по занятым слотам + оценка нового ≤ порога. Порог эмпирический, находится за первые недели.
• Субагенты учитываются. Проверено живым запуском: пустой прогон — 0,708, тот же прогон с одним тривиальным субагентом — 1,198 (кеш-чтение выросло с 16 до 102 тысяч токенов). Значит расход субагентов входит в отчёт родительского шага. Постфактум учёт полный; дыра остаётся только в предсказании. Сколько субагентов поднять — решает исполнитель (или оркестратор при постановке шага); лимитов «не больше N» в задании нет. Демон компенсирует запасом в пороге, а не ограничением исполнителя. Контроль приблизительный — точным он не будет.
• Предугадывание. Демон копит статистику «сколько стоила такая фаза раньше». Оценка следующей фазы не влезает в остаток окна — фазу не начинать, встать на чекпоинте. Дешевле подождать, чем сжечь половину фазы и переделывать.
• Возобновление без потерь. У CLI есть --session-id и --resume: демон выдаёт линии id заранее и после паузы возобновляет ту же сессию — контекст сохранён, фазу повторять не нужно.
• Калибровка. Порог не выдумываем: первые ночи меряем реальную тяжесть разбора одного проекта.

Не простаивать в ожидании. Лимит общий на аккаунт: исчерпано окно — исчерпано для всех линий, тут добирать нечего. Смысл есть в другом случае — остаток ненулевой, но мал для тяжёлого шага: тогда демон берёт из очереди короткий шаг, который по оценке влезает, вместо простоя. Приоритет из фазы 1 остаётся главным, упаковка — только способ не терять хвост окна.

А если демон промахнулся и лимит кончился посреди шага? Шаг падает, работа откатывается к последнему чекпоинту — потеря не больше одного шага, ровно ради этого они режутся мелко. Демон корректирует оценку этого типа шага вверх: промах становится данными. Сессия никуда не девается — после сброса поднимается через --resume. Промахи системные — сигнал резать шаги мельче, а не наращивать запас.

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

• Внутри одного проекта — одна линия за раз.
• Линия никогда не деплоит из своей копии: подтянуть свежий main → влить → прогнать тесты после слияния → только потом деплой.
• Деплой сериализуется: один на проект одновременно.
• Чек-лист «завершено» свой у каждой задачи поверх общей базы. Отдельным пунктом — «ничего из работавшего не сломалось»: отдельная проверка от «новое работает», и подводит обычно вторая.
• Есть интерфейс — headless-браузер прошёл сценарии и прокликал.
• После деплоя health-check; не прошёл — немедленный откат на предыдущую версию, линия в состояние «откатилась, нужен разбор», Антону сообщение.

Проверка не прошла — что дальше. Провал гейта означает, что линия не завершена: она не деплоится и не уходит на приёмку, а получает новый шаг «починить» с описанием того, что упало, и идёт на второй круг сама. Человек не участвует. Потолок — 3 неудачных прохода подряд, дальше линия встаёт и Антону уходит вопрос «не могу пройти проверку, падает вот это, пробовал вот это». Провал health-check уже после деплоя — откат на предыдущую версию и тот же шаг «разобраться».

Кто проверит, что не сломалось то, что ломаться не должно — самый слабый узел, отвечаем честно. Регрессия гоняется целиком, а не по месту правки (в Jarvis 2.0 это ~2400 тестов). Сквозные сценарии интерфейса — весь «золотой путь», а не только затронутый экран. Дыра, которую признаём: непокрытое ни тестами, ни чек-листом автоматически не проверится никак — поэтому линия, тронувшая такую область, обязана либо добавить проверку, либо записать в журнал «область без покрытия, проверял руками так-то». Хук перед деплоем требует одного из двух.

Никогда автономно, независимо от чек-листов: движение денег · отправка писем и сообщений наружу от имени Антона · удаление боевых данных · изменение схемы боевой базы · публикация в публичный доступ · правки в ПланФиксе вне задачи своей линии · смена доступов и токенов.

Хуки-контролёры стоят на трёх границах: перед отправкой вопроса, перед объявлением работы завершённой, перед деплоем. Инструкцию в промпте можно не выполнить, хук — нельзя.

Мак спит на батарее и для ночной фазы не годится в принципе. Проектируем сразу под сервер. Хождение сервера на Мак — временный костыль на переходный период, а не часть архитектуры: цель — перенести на сервер всё, что осталось на Маке, и убрать зависимость целиком.

• ⛔ Обратный туннель Мак → сервер. Мак за NAT, соединение может инициировать только он. Временно, до конца переезда.
• ⛔ Блокер root. На сервере headless-сессии под root падают на пропуске проверок прав. Пока не снято — ни одна линия не запустится.
• ⛔ Второй мозг в сейфе. После перезагрузки сейф закрыт, а исполнитель и судья обязаны в него ходить. Нужен признак «сейф закрыт → линия ждёт» и уведомление Антону.
• ⬜ Playwright на сервер — без него нет проверки интерфейса кликами.

• Цикл (/loop) — изучено 2026-08-19. Что это: сессия повторяет задачу — по фиксированному расписанию либо сама выбирая интервал до следующего пробуждения, есть и полностью автономный режим. Ограничения, которые меняют вывод: расписание живёт только в памяти сессии и умирает вместе с ней · повторяющиеся задачи гаснут через 7 дней · срабатывают только когда сессия не занята · одноразовый claude -p завершается сразу, будить нечего.
  Как оркестратор не годится — не переживёт перезагрузку сервера. Механика правильная, но её место — внутри одной линии, если запускать её живой сессией. Вынесено в развилку 11.
• ⬜ Точный текст ошибки лимита и есть ли в нём время сброса — увидеть на живом исчерпании.

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

Второй вариант остаётся возможной оптимизацией на потом, когда станет видно, сколько реально съедает прогрев.

Цикл самопроверки — внутри шага, а не между шагами

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

• Критерий готовности машинно-проверяемый: команды с ожидаемым результатом — тесты, сборка, сценарий в браузере. Не «убедиться, что хорошо», иначе исполнитель сам себя убедит.
• Работает → прогоняет чек-лист → не сошлось → правит → прогоняет снова. Шаг завершается только на зелёном чек-листе.
• Хук не даёт объявить шаг завершённым, пока чек-лист не пройден — это не пожелание в промпте.
• Потолок — 3 круга. Дальше шаг встаёт: «не могу сойтись с чек-листом, падает вот это». Та же логика, что у гейта деплоя.