Проекты теперь декомпозируются до того, как строятся: замороженный процесс для личных автоматизаций

На Agentic Engineering Infrastructure у контента уже был замороженный процесс: сложный запрос превращается в наряд-заказ, вся очередь записывается на диск, и только потом начинается работа — эту историю мы рассказали в новости MCP-кодинг: один сумбурный запрос становится конвейером разработки. Но личные проекты — автоматизации, которые вы запускаете для себя, вроде «каждое утро пересказывай мои YouTube-каналы в Telegram», — всё ещё строились так, как ИИ обычно строит: модель держала план в голове. Сегодня платформа для агентной инженерии закрывает этот разрыв. Проект теперь декомпозируется ДО того, как его строят, — и сама декомпозиция становится результатом, который вы утверждаете.

Почему автоматизации, которые строят ИИ-агенты, были обречены без декомпозиции

Автоматизация — это не одна задача, а цепочка: забрать это, преобразовать то, опубликовать туда, по такому расписанию, с такими API-ключами. Когда ИИ-агент планирует такую цепочку неявно, ломаются три вещи сразу. План невидим — вы не можете его прочитать и поправить. План хрупок — сбой, сброс контекста или лимит подписки его стирают. И план непроверяем — никто не гейтит, была ли каждая часть действительно специфицирована до того, как её начали кодировать. Внутри команды наш вердикт был жёстким: без глубокой декомпозиции проект такого рода обречён на провал.

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

Граф маленьких узлов, проверенный до начала любой разработки

Каждый узел предложенного графа несёт собственный контракт: заголовок, тип (триггер, действие или преобразование), исчерпывающее описание задачи, инструменты, нужные ключи окружения (никогда не захардкоженные — они задаются через тот же безопасный к пересборке канал, что и любая build-time-настройка), входы и выходы, список дел и узлы, от которых он зависит. Движок проверяет граф зависимостей на циклы и битые ссылки, а затем применяет главный гейт — полноту спецификации. Узел с пустой задачей, отсутствующим описанием или без пунктов списка дел отклоняется — с точным перечнем того, чего не хватает, — и на диск не пишется ничего, пока граф не полон.

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

Один README, объясняющий весь проект, — рождённый из декомпозиции

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

Вызов кодера — отдельный шаг конвейера агентной инженерии

После README движок записывает очередь в ту же систему шагов разработки, которую мы описывали в новости как записи архитектуры становятся шагами разработки: одна насыщенная спецификация на узел плюс отдельный шаг передачи кодеру на узел. Шаг передачи исчерпывающий — фиксированные первые действия (прочитать README, открыть спецификацию), результат, инструменты и ключи одним взглядом, критерии приёмки и протокол завершения. Поэтому когда оркестратор делегирует узел агенту-кодеру, он передаёт ровно одну вещь: номер шага. И передача номера не закрывает узел — оркестратор дожидается реального завершения (шаг закрыт, развёртывание записано), прежде чем открыть любой зависимый узел.

Теперь у автоматизации есть объявленный вход и выход

Любая автоматизация — это преобразование: она читает из входа и пишет в выход. Раньше эта граница была неявной — и ИИ мог «молча» скопировать чужую форму: наш собственный сид «курсы для ребёнка» когда-то вышел как «вход Telegram → выход Telegram», хотя его настоящий выход — автономная интерактивная страница-урок. Теперь граница — это объявленный контракт портов на графе: порты берутся из замкнутого словаря (мессенджер, страница, хранилище, расписание, событие, ручной запуск, внешний API), показываются в шапке проекта и проверяются гейтом — выход, который не производит ни один узел, подсвечивается. И выход — это список: один новостной агент может публиковать пост и на сайт, и в Medium по API одновременно.

Автоматизация, которая создаёт живые страницы

Выход бывает не только сообщением в чат. Автоматизация может материализовать автономную страницу — курс, анкету, доску Kanban — через шлюз между системой автоматизаций и системой генерации сайта. Такая страница живёт сама после прогона и даже собирает данные обратно (ученик заполняет квиз — и это снова вход). Шлюз — типизированная граница с двумя плоскостями: одной автоматизация страницу создаёт и модерирует, другой — взаимодействует с ней в рантайме (добавить карточку, передвинуть карточку). Всё объявляется манифестом, а не пишется руками под каждую доску.

Самодостаточность по построению: навык в каждом агенте и MCP-инструмент

Как и любая способность платформы, замороженный процесс проектов не зависит от существования оркестратора. Он поставляется самодостаточным навыком в каждой агент-сущности — одинокий агент, даже рабочее пространство с единственным CLI без центрального мозга, запускает идентичный процесс напрямую. Для разговорного пути тот же движок открыт как MCP-инструмент уровня владельца, `owner_projects_orchestrate_decomposition`, — с тем же dry-run, тем же наряд-заказом и тем же токеном подтверждения. Вместе с ним едет ещё один пункт операционного контракта: процесс покрывает только проекты и автоматизации — у публичных страниц сайта свой замороженный конвейер, и эти два никогда не смешиваются.

Планы бесполезны, но планирование — это всё. Фокус в том, чтобы сделать артефактом само планирование.