Blueprint

Blueprint: AI Team Across Engines

Штаб на сильной модели, воркеры по цене задачи, роль описана один раз и работает на любом движке

5 сентября 2026 г. · 43 мин чтения
Для кого

Для тех, кто ведёт несколько проектов в одиночку и хочет, чтобы AI-сессии не умирали вместе с контекстом

Blueprint: AI Team Across Engines

Status: living · v2.0, 13 октября 2026. Так работает команда из одного человека и нескольких сотен AI-запусков в неделю: штаб на Claude Opus 5.5, исполнители на Opus и Sonnet, а Codex, Grok и Gemini — каждый на своём жанре. Для масштаба одна неделя, 5 – 11 октября 2026: 260 запусков тиммейтов, 22 роли в работе на четырёх движках, 189 закрытых задач. Всё ниже — из практики, включая грабли. До v2 блюпринт назывался «AI Team on Fable + Codex»: штаб тогда жил на Fable, а движков было два.

Ты открываешь Claude Code, ставишь самую сильную модель и делаешь в одной сессии всё подряд: код, тексты, ресёрч, переписку. Через день контекст забит, решения растворились в чате, половина токенов ушла на рутину, которую сделала бы модель втрое дешевле. Рядом лежат подписки Codex и других движков, но инструменты живут в разных мирах и не знают, что делает другой. Сессия умирает — и вместе с ней всё, что она «помнила».

Этот Blueprint описывает другую модель: одна долгоживущая штабная сессия на сильной модели держит контекст и решения, работу делают одноразовые headless-воркеры на моделях по цене задачи, роли описаны один раз и работают на любом подключённом движке, а всё, что важно, живёт в файлах, а не в чатах. Штаб не исполнитель, а менеджер. Файл — единица работы. Человек говорит последнее слово по короткому списку необратимых действий. Дисциплину держит код, а не обещания модели.

Что ты получишь

  • HQ-сессия, которая не умирает: живёт через resume, при старте получает блок «состояние мира» и продолжает с того места, где остановилась вчера. Штаб один: штатный запуск отключает фоновые форки, а стартовый хук распознаёт дубль и бережёт состояние основной сессии.
  • Флот воркеров: каждая задача — отдельный headless-запуск в tmux по брифу-файлу, с отчётом-файлом, маркером выхода и сторожем; модель выбирается явно под задачу.
  • Матрица моделей: штаб на Opus 5.5 с максимальным effort, содержательная работа на Opus 5.5 (effort high), механика на Sonnet 5.5 со средним effort. У Codex та же пара ярусов: Astra для содержательного, Sol для механики. Grok — третий голос в спорах и механика по точному брифу, Gemini — пока только механика. Фоновые задачи (например, память между сессиями) — на дешёвой облачной модели (у нас наблюдатель на Haiku 4.5) или на локальной, если есть железо.
  • Тиммейты вне вендора: роль описана один раз карточкой в базе заметок, её память лежит рядом, и запускатель отдаёт одну и ту же роль любому движку из её списка.
  • Реестр решений с мячом: любая развилка для человека — карточка с дефолтом и путём к артефакту, а не вопрос в чате, который утонет. Карточка знает, у кого сейчас ход и чего именно ждут от человека.
  • Гейты дисциплины в коде: ответ без карточки, развилка в чате, работа руками штаба, мёртвый монитор инбокса, печать секретов — ловит хук, а не память модели.
  • Память, которая переживает сессии и вендоров: карты репозиториев, память ролей, файловая память штаба, конституция команды.
  • Правило синхрона: действия одного движка всегда видны другим через след в файлах.

Как применить

  1. Открой coding agent (Claude Code) в домашней директории или в корне своей базы заметок — штаб живёт там, где сходятся все проекты, а не внутри одного репозитория.
  2. Покажи ему этот Blueprint: «Собери мне AI-команду по этому Blueprint. Начни с раздела „Вопросы для адаптации“».
  3. Агент соберёт первый слой: карточку штаба с правилами, глобальный CLAUDE.md с механикой, карту первого репозитория, реестр моделей, запускатель воркеров, файл решений. Это день первый.
  4. Неделя первая — привычка: каждая задача длиннее получаса уходит воркеру по брифу; штаб руками делает только то, где бриф дороже самой работы.
  5. Неделя вторая — роли и второй движок: заводишь две-три роли карточками в базе заметок, конституцию на пять–восемь статей, подключаешь Codex (или другой CLI) через тот же запускатель.
  6. Неделя третья — гейты: каждое правило, которое модель нарушила дважды, уезжает в хук.

Когда использовать

  • Ты один, но проектов больше трёх, и они живут параллельно: сайт, контент, продукт, операционка.
  • Ты платишь больше чем за один AI-инструмент (Claude, Codex, Grok, Gemini) и хочешь, чтобы они работали одной командой, а не по очереди.
  • Тебе важны решения и история: что решили, почему, где артефакт, — а не только результат.
  • Ты готов принять правило «файл — единица работы» и писать брифы вместо устных поручений в чате.

Когда не использовать

  • Один проект, один репозиторий, работа линейная — хватит одной сессии с хорошим CLAUDE.md.
  • Ты не готов держать tmux, скрипты запуска, хуки и файлы состояния: этот Blueprint про операционку, а не про «умный промпт».
  • Нужен полностью автономный агент без человека в петле: здесь человек в петле по выбору, а не потому, что не доросли.

Ключевая идея

Штаб — менеджер, не исполнитель. Модель штаба дорога не токенами, а контекстом: каждая рутина, сделанная её руками, вытесняет из окна то, ради чего она нужна, — решения, историю, суждение. Поэтому граница записана матрицей «сам или агент». Сам штаб ведёт реестр решений, пишет брифы, принимает отчёты и делает правку в пару вызовов, когда исполнитель ясен. Агенту уходит любой новый артефакт для человека, код дальше одной строки, деплой, ресёрч дольше двух поисков и любая работа в репозитории, у которого есть владелец нити. Исключение — только вслух, фразой «сам: <причина>».

Модель — по задаче, не по привычке. Содержательная работа (код-дизайн, продукт, деньги, ресёрч с выводами) — Opus 5.5 с effort high. Механика по точному чек-листу (смоуки, деплой по плану, переносы файлов, перегенерации по готовым промптам) — Sonnet 5.5 со средним effort. Штаб — Opus 5.5 с максимальным effort, потому что его ошибка стоит дороже всех. У других движков то же деление по ярусам. Модель задаётся в команде запуска явно, её id живёт в одном реестре; молчаливая подмена запрещена.

Файлы, не чаты. Бриф — файл. Отчёт — файл. Решение — карточка с путём к артефакту. Правило команды: «есть артефакт — была работа; расплывчато — не сделано». Чат — это шум, который сгорает при компакции; файл переживает и сессию, и модель, и вендора.

Роль одна, движков много. Роль привязана к жанру, а не к движку: она описана один раз, и Claude, Codex, Grok и Gemini получают одну и ту же. Второй движок нужен не как запасной штаб, а как другая голова: ревью, независимая критика, длинные генерации, дешёвая механика. Требование к каждому одно: он должен видеть, что сделали другие. Значит, обмен идёт через файлы общего формата — брифы, отчёты, карточки, — а не через копипаст; что именно каждому движку можно читать, задаётся отдельно.

Второе мнение — по цене решения. По умолчанию — «Opus делает, Astra читает»: исполнитель на одном вендоре, ревьюер на другом. Полный консилиум из трёх голосов — только когда решение необратимо или меняет то, как человек работает с системой. Третий голос (у нас Grok) зовут, когда первые два разошлись, а не ради кворума.

Последнее слово — у человека, но список короткий. Не «спрашивай на всё», а один явный список: отправка сообщений людям, публикация, платежи, деплой новых систем, миграции продовой базы, продовая конфигурация, удаление данных. Всё остальное — по умолчанию делаем и докладываем. Одно названное исключение из «отправки людям»: регулярные рубрики по расписанию (у нас — недельная рубрика в двух спейсах Team2Team по launchd) уходят без человека в момент поста, но по заранее записанному слову человека на эту рубрику, этот спейс и этот ритм, Опенер у рубрики шаблонный; если за неделю есть находки, дайджест пишет LLM без единого инструмента, а условия отправки, адрес и сам сетевой вызов держит скрипт-обёртка в пределах заранее одобренных рубрики, аудитории и расписания. Исключение живёт в документе, а не в голове: без записи это нарушение.

Дисциплина — в коде, а не в обещаниях. Модель, которая сказала «больше так не буду», после компакции не помнит обещания. Правило, нарушенное дважды, становится хуком: он видит ход штаба и останавливает его или хотя бы напоминает, пока нарушение не исправлено или не названо вслух. Подробно — раздел «Гейты дисциплины в коде».

Архитектура

Человек
  │  карточки решений (дашборд) + чат + мобильный мост
  ▼
HQ — Claude Code, Opus 5.5, effort max, одна бесконечная сессия через resume
  │  пишет брифы, читает отчёты, ведёт реестр решений, память, handoff
  ├──► Запускатель: карточка роли + бриф → движок и модель из реестра
  │      ├─ Claude — `claude -p` в tmux, Opus 5.5 / Sonnet 5.5
  │      ├─ Codex  — `codex exec` в tmux, Astra / Sol
  │      ├─ Grok   — третий голос и механика по точному брифу
  │      └─ Gemini — только механика по точному брифу
  │      бриф → отчёт-файл → EXIT в лог → сообщение или секция в инбокс HQ
  ├──► Нити Codex у человека — прямо в базе заметок; HQ → Codex — лента-файл
  └──► Наблюдатели — Monitor на инбокс, сторожа джоб, launchd-джобы, Stop-гейты
Общая земля — формат один, доступ по роли и движку: карточки ролей ·
брифы, отчёты, карты репозиториев · конституция; база заметок, инбоксы,
реестр решений и журнал — по правам конкретной роли

HQ. Одна интерактивная сессия Claude Code на Opus 5.5. Рестарт — команда-обёртка: она делает resume живого id из файла состояния и сразу подаёт стартовое сообщение «прочитай правила и состояние мира». При каждом старте, resume и компакции хук кладёт в контекст блок «состояние мира»: последний handoff, решения со сроком, непрочитанные секции инбокса, состояние ролей, осиротевшие процессы, путь и хеш карточки с правилами штаба. После компакции штаб перечитывает свою карточку целиком: саммари помнит, что правила читали, но не сами правила. Раз в день-два HQ пишет handoff-ноту: что горячо, что ждёт человека, что делать первым. Штаб один: обёртка отключает фоновые форки, стартовый хук берёт лок, и вторая копия получает стоп первой строкой и не трогает состояние основной — почему это пришлось кодировать и где у защиты границы, рассказано в граблях.

Воркеры. Каждая задача — tmux-сессия job-<slug> с headless-запуском по брифу-файлу. Лог пишется в файл через tee, в конце — маркер EXIT=<код> тем же файлом (сторож читает файл, а не экран). Отчёт — файл в scratchpad/ репозитория, не во временной папке. У каждой джобы есть карточка в реестре, слаг джобы совпадает с её id: запуск записывает попытку в карточку, а маркер выхода сам возвращает ход штабу на приёмку. Имя штаба, которому воркер шлёт отчёт, подставляет запускатель из файла состояния штаба — шаблонное «main» код не печатает.

Роли. Роль — карточка в базе заметок: миссия, зона, каноны, границы, на каких движках она может работать и чем запускается по умолчанию. Рядом лежит Memory.md: грабли, факты, решения человека, и ведёт её сама роль на любом движке. Id сессий конкретного движка — state.json в домашней папке агента: это не знание, а адрес. Resume-first только когда контекст роли реально нужен (многоходовая задача, знание кодовой базы); короткая самодостаточная задача — свежая сессия, толстую историю не таскаем. Подробно — разделы «Named teammates и обычные воркеры» и «Тиммейты вне вендора».

Другие движки. Воркер Codex, Grok или Gemini поднимается тем же запускателем по тому же протоколу: бриф-файл, отчёт-файл, маркер выхода. Межсессионных сообщений Claude у Codex нет, поэтому его пуш в штаб — маленький скрипт, который дописывает секцию в инбокс-файл, а Monitor штаба на этот файл будит HQ. Обратно — append-only лента в инбокс Codex: её читает любая нить Codex, которую человек открыл в базе заметок. Доставлено — это ответный след: отчёт, артефакт или секция в инбоксе штаба. Долгоживущую главную сессию Codex с курсором мы строили и свернули — это в «Масштабировании».

Реестр решений. JSON-файл карточек. Обязательные поля: тип (решить / подтвердить / подумать / сделать), вопрос с абзацем контекста, дефолт, цена у «подтвердить», путь к артефакту. Поверх этого у карточки есть мяч — записанный факт, у кого сейчас ход, — и вид запроса к человеку, по которому дашборд рисует главную кнопку. Человек отвечает кнопкой или строкой, ответ пишется в тот же файл и в инбокс — штаб просыпается и действует. Карточка без дефолта — это переложенная на человека работа; карточка «подтвердить» без цены — автоматическое «да». Подробно — раздел «Карточки: мяч, запрос, очередь».

Память. Три слоя: карты репозиториев (CLAUDE.md в корне: стек, структура, точки входа, как перезапустить и проверить), память ролей рядом с их карточками, файловая память штаба (один факт — один файл, индекс грузится при старте). Плюс память между сессиями плагином: его наблюдатель делает тысячи фоновых вызовов в день, поэтому живёт на самой дешёвой модели класса Haiku. Локальный вариант мы пробовали и откатили: модель 27B держала 30 ГБ памяти и постоянно грузилась и выгружалась под восемью сессиями; вернёмся с моделью поменьше.

Named teammates и обычные воркеры

Воркер — это процесс. Named teammate — это роль с именем, памятью и нитью. Разница в трёх вещах: что переживает задачу, кто отвечает за нить проекта и как штаб к исполнителю обращается.

Обычный воркер — одноразовый headless-запуск по брифу. Свежая сессия, весь контекст помещается в бриф, после отчёта процесс умирает и не оставляет ничего, кроме артефактов (отчёт, коммит) и записи в журнале команды. Это правильный инструмент для самодостаточной задачи до получаса: перегенерировать картинки по готовым промптам, прогнать смоук по чек-листу, перенести файлы, собрать данные по известным путям, вписать правку по точному описанию. Модель — по жанру задачи: Sonnet для механики, Opus для содержательного разового.

Named teammate — роль вроде producer, ops, web, designer, toolsmith, analyst, envoy или продуктовой роли «один продукт — один инженер». У роли есть пять вещей, которых нет у воркера:

  • Определение роли. Карточка в базе заметок: кто это, за что отвечает, какие каноны читает первыми, на каких движках может работать. У web — канон деплоя и OG-гейт, у ops — «бэкап до любой хирургии данных», у envoy — «черновик, никогда не отправка».
  • Память роли. Memory.md рядом с карточкой: грабли, факты, решения человека по её жанру. Роль обновляет память сама в конце задачи, на каком бы движке ни работала; штаб дописывает по отчётам. Это не дневник, а список «что я знаю, чего нет ни в коде, ни в брифе»: где лежат бэкапы прода, какой проект в облаке правильный, что человек запретил навсегда. Бюджет — около 40 КБ: сверх него запускатель велит роли унести старое в архив по месяцам.
  • Состояние. state.json: id последней сессии, репозиторий, дата, последняя задача. Оно даёт resume: следующая задача по той же нити продолжает сессию с контекстом кодовой базы и предыдущих ходов, а не начинает знакомство заново.
  • Владение нитью. Континуитет исполнителя: кто ведёт нить — цепочку связанных задач, — тому и следующая задача по ней, даже если по жанру напрашивается другая роль. Смена — с записанной причиной и handoff’ом: статус, артефакты, открытые риски, следующий ход. Так у продукта появляется «свой инженер», который помнит, почему сделали именно так.
  • Адрес. Штаб обращается к роли по имени через запускатель (--role web --brief …), а протокол — роль, память, конституцию, отчёт — запускатель дописывает в промпт сам. Люди в команде тоже знают адрес: «это к ops».
Воркер Named teammate
Живёт одну задачу нить из многих задач
Контекст весь в брифе бриф + карточка роли + память + сессия
Память нет: журнал и артефакты Memory.md у карточки + state.json
Запуск всегда свежая сессия resume-first, свежая когда контекст не нужен
Модель по жанру задачи из карточки роли, бриф может перебить
Отвечает за результат задачи нить проекта, карту репо, каноны
Когда до получаса, самодостаточно повторяющийся жанр, кодовая база, долгие нити

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

Что роль делает лучше воркера. Помнит прод: где бэкапы, как перезапускать, какие смоуки обязательны. Читает карту репозитория не как новичок, а как вернувшийся. Ловит, что изменилось с прошлого визита, через git log в начале задачи. Знает решения человека по своему жанру: что запрещено, что одобрено постоянно. Продолжает многоходовую задачу без пересказа истории в брифе.

Чем платишь. Resume тащит историю сессии — дороже и медленнее, поэтому короткую самодостаточную задачу роль получает свежей сессией, а не продолжением. Память протухает, если её не ревьюить. Две инстанции одной роли одновременно ломают состояние: id сессии перезаписывается; параллельные задачи одной роли идут по очереди или вторая уходит безымянному воркеру. Роль без владельца-человека превращается в свалку заметок.

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

Роль и вендор. Роль привязана к жанру, не к движку: у нас curator, владелец энциклопедий и деков, по умолчанию работает на Codex, а web и toolsmith — на Claude, и любой из них может уйти на другой движок из своего списка. Как это устроено — следующий раздел.

Тиммейты вне вендора: роль один раз, движок любой

До 8 октября 2026 роль жила в файлах Claude: описание агента в его папке, память — в ~/.claude/teammates/<role>/MEMORY.md. Другие движки видели её через эти файлы или через отдельную инструкцию. Теперь канон один и лежит там, где его читают все, — в базе заметок.

Карточка роли. Teammates/<Роль>/<Роль>.md в базе заметок: миссия, зона, каноны жанра, границы, форма результата, эскалация. Во фронтматтере — platforms (на каких движках роль может работать), executor (алиас модели по умолчанию) и contour (открытый или закрытый контур). Карточку правят словами, как документ, а не как конфиг.

Запускатель кладёт карточку в промпт любому движку. Секцией «Роль» — одинаково для Claude, Codex, Grok и Gemini. Движок вне platforms — отказ кодом, а не предупреждение: роль, которой нельзя на Gemini, на Gemini не запустится даже по ошибке в брифе. Алиас модели чужого движка (--model sol) переключает движок сам. Одинаковая карточка роли не означает одинаковых прав: platforms решает, можно ли запустить роль на движке, а доступ к базе заметок и данным у каждого движка задан отдельно — например, Gemini у нас получает только задачи без секретов и данных людей: закрытые роли, брифы и папки запускатель отвергает ещё до старта.

Файлы под конкретный движок — производные. Описание агента для Claude генерирует синк-скрипт из карточки; руками такие файлы не правят, хук блокирует правку. Нативные механики движка (агент-тип, субагенты) продолжают работать, а правда остаётся одна.

Память роли пишет любой движок. Memory.md рядом с карточкой, история — в git базы заметок. В домашней папке агента остался только state.json с id сессий: адрес, а не знание.

Закрытые роли. Роль, которая ведёт личный контур, устроена так же, но живёт в закрытой папке: в общем ростере видна только счётчиком, её память не попадает в общие отчёты и не уходит к ролям другого контура.

Ярусы, а не бренды. Реестр моделей один на всех — models.json: алиасы opus, sonnet, astra, sol, grok, gemini, gemini-flash, плюс hq — «штаб делает сам». В нём же способности движка в нашей интеграции: режим плана для Gemini у нас пока отключён — его файл плана не подключён к карточкам, — и дашборд не предлагает его Gemini-исполнителю. Деление идёт по ярусам: Opus и Astra — содержательное; Sonnet, Sol и Gemini Flash — механика по чек-листу. Grok у нас — третий голос в спорах и механика по точному брифу. Gemini пока только механика: в одном сравнительном аудите 8 октября 2026 (сверка документации с кодом) у Gemini 3.1 Pro подтвердились 3 из 5 находок, одна оказалась частичной и одна ложной, а у Grok 4.7 подтвердились все 11. Это один прогон, ориентир, а не замер.

Трикстер. Отдельная роль на Grok с персоной провокатора: переворачивает доску и ищет ход, который все пропустили. Зовётся только по явному запросу человека — кнопкой на карточке или фразой «спроси трикстера»; по своей инициативе штаб его не поднимает. Исполнитель получает от его мнения только то, что человек явно взял, — пересказом в одну-две строки, без голоса персоны.

Что это дало. За неделю 5 – 11 октября 2026 запуски разошлись по движкам так: Claude 194, Codex 51, Grok 10, Gemini 5. Роль, у которой в platforms два движка, переезжает между ними без переписывания: меняется одна строка запуска.

Карточки: мяч, запрос, очередь

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

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

Вид запроса. Когда мяч уходит человеку, реплика обязана сказать, чего от него ждут, — одним из пяти видов. Дашборд рисует по нему главную кнопку:

  • принять готовый результат — «✓ Принять» закрывает карточку, правки — текстом;
  • разрешить следующую работу — на кнопке написано, что будет после «да»;
  • рука — ручной шаг человека, кнопка «✓ Сделал»;
  • текст — нужен ответ словами, поле с вопросом над ним;
  • выбор — кнопки вариантов.

Реплика без вида запроса — отказ скрипта. Обход есть, но с причиной в лог, и число обходов попадает в недельный разбор.

Рубрики — по тому, у кого мяч. Вкладки человека: «Сделать» (выбор, который штаб не вправе сделать сам, или ручной шаг), «Подтвердить» (штаб готов сделать сам, человек — право вето), «Подумать» (ничего не заблокировано, но есть триггер — дата или событие; без триггера это идея, а не карточка). Очередь команды живёт в отдельном виде и в счётчики человека не попадает.

Ревью человека перед закрытием. Результат, о котором просил человек, штаб сам не закрывает: нужно его «да» — кнопкой, репликой «да/ок» или отдельной approve-карточкой на тот же артефакт. Повод — картинка и страница уехали в «сделано», а человек их так и не увидел.

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

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

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

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

Гейты дисциплины в коде

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

Что у нас ловит код:

  • Ответ без карточки. Человек спросил в чате, штаб ответил текстом, а в ходе нет ни команды реестра, ни ссылки на карточку, — ход не завершается. Чат один на всё, ответы в нём тонут: справка уходит в лог ответов, решение — в approve-карточку. Побег — «без карточки: <причина>».
  • Развилка в чате. В последнем сообщении хода маркер выбора — «да или нет», «выбери вариант», пронумерованный список с вопросом — без карточки в том же ходе. Ход не завершается: заведи карточку или перепиши как информирование. Повод — штаб спросил «да» на настройку Cloudflare прямо в чате.
  • Мяч не передан. Штаб прочитал ответ человека по карточке, но не записал, у кого теперь ход, — ход не завершается.
  • «Сам или агент». Мягкий гейт: больше трёх правок одного файла вне списка «сам» или новый артефакт для человека, а запуска воркера в ходе нет, — одно напоминание «делегируй или назови причину». Не блок; счётчик идёт в недельный разбор.
  • Мёртвый монитор инбокса. Штаб просыпается от монитора на инбокс-файл, а монитор пишет heartbeat. Когда heartbeat уже появился, а потом протух или сторож осиротел, ход не завершается, пока монитор не перевзведён; до первого heartbeat и при ошибке самой проверки гейт пропускает. Цикл монитора один, разрешённый: самодельные циклы теряли секции, пришедшие за секунды до перевзвода.
  • Печать секретов. До выполнения хук блокирует команду, которая выведет секрет на экран: docker compose config без тихого флага, чтение .env печатающей командой, env без фильтра, echo секретной переменной, вывод хелпера ключей на экран. Блок ловит известные способы печати, а не любую утечку. После любой команды второй хук ищет в выводе шаблоны ключей (14 видов) и, если нашёл, шлёт алерт штабу — без самого значения; это сигнал о случившемся, а не защита. Повод — за один день значение секрета дважды ушло в транскрипт воркера. Честная оговорка: это хуки Claude, другие движки ими не покрыты. Для Grok и Gemini хелпер секретов дополнительно отказывает в выдаче значения, но это лежачий полицейский на отдельных командах, а не изоляция окружения или keychain; у Codex такого запрета нет.
  • Одна HQ. Лок на старте, стоп первой строкой для второй копии, блок промптов фоновой копии; интерактивная копия получает только предупреждение. Подробно — в граблях.
  • Реестр — только скриптами. Прямая правка JSON заблокирована. Скрипт добавления отказывает карточке без контекста, «подумать» без триггера и решению с дефолтом «да/нет»; скрипт закрытия — закрытию без артефакта.

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

Модели внутри контура Codex: Astra и Sol

Тот же принцип «модель по цене задачи» работает и у второго вендора, и там он даёт два слоя, которые не исключают друг друга.

Слой 1 — штаб выбирает модель на запуске. Воркер Codex стартует как codex exec -m <модель> -c model_reasoning_effort=<уровень> по брифу-файлу. Алиасы моделей живут в одном реестре для всех движков (у нас models.json: opus, sonnet, astra, sol, grok, gemini и другие), его читают и запускатель, и селектор исполнителя в дашборде; алиас чужого движка переключает движок сам. Штаб не помнит id моделей и не пишет их в брифы руками — он говорит «механика» или «содержательное», а реестр переводит это в модель.

Слой 2 — субагенты внутри одной сессии Codex, каждый на своей модели. У Codex есть штатный флаг multi_agent и кастомные агенты: по одному TOML-файлу в ~/.codex/agents/ (личные) или .codex/agents/ в проекте (командные, грузятся только в доверенном проекте). В файле — name, description, developer_instructions, а также обычные ключи конфига: model, model_reasoning_effort, sandbox_mode, mcp_servers. Всё ниже, включая оба примера, — конфигурация сборки v0.153.3, которую мы проверяли 09.09.2026, а не нынешний контракт CLI: на ней пропущенный ключ наследовался от родителя, лимиты задавались [agents] max_threads (по умолчанию 6) и max_depth (по умолчанию 1: ребёнок не спавнит внуков), встроенные роли были default, worker, explorer, и своя роль с тем же именем перекрывала встроенную. Имена ключей и дефолты с тех пор меняются — перед сборкой сверяй со справкой своей версии Codex.

# .codex/agents/scout.toml — дешёвая разведка, только чтение
name = "scout"
description = "Read-only разведчик по кодовой базе на дешёвой модели."
model = "gpt-6.1-sol"
model_reasoning_effort = "low"
sandbox_mode = "read-only"
developer_instructions = """
Ищи точечно, не сканируй каталоги целиком. Отдай факты и пути, синтез сделает родитель.
"""
# .codex/config.toml — реестр и лимиты
[features]
multi_agent = true

[agents]
max_threads = 4
max_depth = 1

[agents.scout]
description = "Read-only разведчик на дешёвой модели."
config_file = "agents/scout.toml"

Проверено живьём 09.09.2026 на Codex v0.153.3: родитель на gpt-6-astra (effort high) поднял двух субагентов из таких файлов, и в журналах сессий у каждого своя модель и свой effort — scout на gpt-5.6-sol / low, builder на gpt-6-astra / medium. Жалоба с форума за июль 2026, будто после 5.6 субагенты наследуют модель родителя, на этой сборке не воспроизводится. Проверять надо именно по журналам (~/.codex/sessions/…/rollout-*.jsonl, поле model в turn_context), а не по словам субагента о себе. С 01.10.2026 алиас sol у нас указывает на gpt-6.1-sol; на новой модели зонд не повторяли.

Что мы знаем о цене и качестве. Ночной бенчмарк 06.09.2026 на наших задачах: там, где источник лежит перед моделью (сверка фактов, счёт по данным), Opus, Astra и Sol дали одинаковый максимум во всех повторах, а содержательная задача на суждение (месяц транскриптов: обещания, сквозные сюжеты, решение) развела их — Opus 0.865, Astra 0.761, Sol 0.698 при цене прогона $0.77 / $1.01 / $0.39. Вывод тот же, что у пары Opus/Sonnet: механику отдавать дешёвой модели без потери, суждение оставлять сильной.

Где здесь экономия, а где нет. Субагенты в сумме тратят больше токенов, чем одна сессия: у каждого свой контекст и свои вызовы инструментов. Выигрыш даёт не параллельность, а дешёвая модель на дешёвой роли: explorer на Sol read-only, worker на средней модели, судья или родитель на сильной. Классическая ошибка — поставить сильную модель родителю и ничего не задать детям: они молча унаследуют её, и «экономная» схема выйдет дороже одной сессии.

Как выбрать слой. Слой 1 — когда задача самодостаточна и её можно описать брифом: штаб видит модель в команде запуска, в журнале команды и в карточке; это наш дефолт. Слой 2 — когда одна сессия Codex сама разбивает работу на разведку и исполнение и ей нужна параллельность внутри задачи; тогда модели детей фиксируются в TOML-файлах проекта и уезжают в репозиторий вместе с кодом.

Ключевые принципы

  1. Бриф — только тело. Задача, границы, дельта, след. Протокол — роль, память, карту репо, конституцию, git log / status, путь отчёта, имя штаба, обновление памяти, кодификацию граблей — дописывает запускатель в промпт рядом с брифом. Повод: каркас вырос с 17 до 41 % брифа, и штаб каждый раз писал его заново. Строки протокола код печатает всегда — тело брифа их не гасит.
  2. Модель явно, effort явно. Штаб — max, Opus-воркеры — high, Sonnet-механика — medium. Effort воркера задаётся явно (Opus — настройкой модели, Sonnet — переменной окружения его процесса), а переменная штаба не должна протечь в воркеров через tmux-сервер — запускатель её снимает. Молчаливый фоллбэк на другую модель запрещён: не получилось запустить — скажи.
  3. Всё дольше тридцати секунд — в tmux. Не foreground (блокирует ход), не фоновая оболочка (умирает с сессией). Сторож — цикл until с таймаутом на файл лога, по одному на джобу; общий наблюдатель на много джоб слепнет.
  4. Артефакты — в постоянных местах. Отчёты в scratchpad/ репозитория, не в /tmp: ребут стирает временные папки вместе с историей работы.
  5. Один репозиторий — один пишущий. Перед сборкой и деплоем — инбокс и git status: чужие незакоммиченные файлы уезжают паровозом. Если человек сам сидит в этом репозитории интерактивной сессией — воркера не поднимать, задачу отдать ей.
  6. Секреты — только в keychain и окружении. Никаких .env в коде, никаких ключей в отчётах, логах и коммитах. Скрипты берут ключи через хелпер; гарды снижают риск печати, но не заменяют ограничения доступа (раздел «Гейты»).
  7. Кодифицируем, а не запоминаем. Правило, сработавшее дважды, уходит в хук, гейт, скрипт или манифест процесса. Волатильное — модель, цена, путь, лимит — в конфиг, не в тело кода и промпта.
  8. Обратимость по умолчанию. Бэкап до изменения, откат одним ходом. Необратимое — только по списку человека.
  9. Слом предпосылки — не повод молчать. Одобренный подход упёрся в новый факт: замена обратима и цель та же — делаем и докладываем; сдвигается цель, деньги, люди, публичность или границы — стоп и вопрос.
  10. Синхрон движков. Каждая содержательная работа оставляет след, который читают другие: отчёт или коммит, дневная нота, журнал команды, файл текущего контекста для Codex. В каждом брифе Codex — строка про след.
  11. Второе мнение — по цене решения. Opus делает, Astra читает; три голоса — для необратимого решения или изменения того, как человек работает с системой; Grok — при расхождении первых двух.
  12. Канал итогов — карточка. Мессенджер — только по просьбе человека.

Workflow

Утро. Ещё до человека скрипт кладёт в инбокс утреннюю очередь команды, и штаб поднимает по ней воркеров, если позволяет лимит. Рестарт штаба: обёртка подаёт стартовое сообщение, хук показывает handoff, карточки со сроком, инбокс, роли, сирот в tmux и карточки, где мяч завис. Одно-два действия на разгребание (перевзвести монитор инбокса, убить сирот), потом задачи.

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

Отчёт пришёл. Штаб проверяет факты, которые расходятся с его контекстом (дата имени файла — не дата события; «сделано» без пути — не сделано). Результат для рук человека — мяч человеку с видом запроса; остальное закрывает только с артефактом. Паспорт нити — тем же ходом. Дописывает дневник и контекст для Codex. Убивает tmux-джобу после сбора результата.

Человек ответил по карточкам. Ответ → действие (закрыть в лог или запустить воркера), реплика в тред карточки, мяч — тому, у кого теперь ход, отметка «обработано» в инбоксе. Ответ карточку не закрывает — закрывает штаб артефактом или человек своим «да».

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

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

Компоненты решения

  • Карточка штаба — правила штаба для любой платформы: миссия, что не делегируется, канал выборов, исполнители, континуитет, консилиумы, отчётность. Лежит в базе заметок рядом с карточками ролей.
  • Глобальный CLAUDE.md и скиллы — механика: команды, флаги, пути, пороги. Правила штаба здесь не повторяются — только ссылка на карточку: двойное ведение уже ловило дрейф. Скиллы грузятся по требованию — перед брифом, перед карточкой.
  • Карты репозиториев — CLAUDE.md в корне каждого активного репозитория. Воркер стартует с cwd в репо и подхватывает карту сам; карты нет — первый воркер пишет её до задачи; поменял топологию — обновляет тем же ходом.
  • Роли — карточка и Memory.md в базе заметок, state.json у агента; синк-скрипт генерирует из карточек файлы под движки.
  • Реестр моделей — models.json: алиас, id, движок, способности движка. Реестр един для запуска воркеров и выбора исполнителя в дашборде; модель самого штаба пока закреплена отдельно, в его обёртке.
  • Запускатель — один скрипт: --role, --brief, --model, --effort, --card, --mode plan|exec, --fresh, --dry-run. Читает карточку роли и проверяет platforms, выбирает движок по алиасу, resume или свежую сессию, пишет каркас протокола рядом с брифом, лог с маркером выхода, событие в журнал команды и попытку в карточку, ретраит перегрузку. Руками собирать команду — только для случаев, которые он не покрывает.
  • Брифы и отчёты — scratchpad/brief-<slug>.md (тело), brief-<slug>.prompt.md (каркас, его пишет запускатель) и scratchpad/report-<slug>.md в репозитории задачи; scratchpad/ в .gitignore и в исключениях деплоя.
  • Реестр решений — pending-decisions.json с мячом, видом запроса, нитями, сроками и приоритетом; скрипты decision-add / decision-reply / decision-close / decision-link с гейтами; дашборд с кнопками.
  • Инбокс-файлы — инбокс штаба: markdown с секциями ## <источник> <дата время> — <тема>; писатели — мост из мессенджера, алерты продовых ботов, Codex, ответы по карточкам, утренняя очередь. Штаб держит на нём один Monitor и помечает обработанные секции. Лента для Codex — append-only, без курсора.
  • Журнал команды — запускатель пишет события «запуск / готово» с ролью, движком, моделью и задачей в jsonl; из него строятся и вьювер в дашборде, и недельная сводка команды.
  • Хуки-гейты — раздел «Гейты дисциплины в коде»: блокирующие, напоминающие и детекторы после факта; конфиг, выключатель и побег — у каждого свои.
  • Конституция — восемь коротких статей с «уликой» у каждой: последнее слово у человека (и единый список human-only); факт держится на источнике; обратимость по умолчанию; слом предпосылки — не повод молчать; есть артефакт — была работа; кодифицируем, а не запоминаем; контуры изолированы (закрытые аудитории не смешиваются); континуитет исполнителя (нить остаётся у того, кто её ведёт). Правится только словом человека, с версией и историей.
  • Мосты — мессенджер → инбокс (входящие с телефона), «отправить от моего имени» только через карточку-подтверждение с одноразовым токеном.
  • Наблюдатель памяти на дешёвой облачной модели (у нас Haiku 4.5) или на локальной: OpenAI-совместимый эндпоинт локального сервера, thinking выключен прокси, потому что фоновой сжимке он не нужен, а время режет в шесть раз. Локальный вариант окупается только на модели, которая помещается в память вместе с остальной работой.

Стартовый комплект

Это спецификация для сборки своей системы, а не установочный пакет: run-teammate, decision-* и дашборд — имена наших собственных скриптов, и агенту предстоит написать их аналоги у тебя.

Бриф — только тело:

---
decision: <ссылка на карточку>
---
# Бриф <роль>: <что сделать>
Карточка: <ссылка>. Что решил человек: «<цитата>».
## Что сделать
1. … (критерии проверки, откат)
## Границы
- что НЕ трогать; что требует слова человека
## След
Отчёт: `<repo>/scratchpad/report-<slug>.md`. К карточке привязать: …

Каркас, который запускатель пишет рядом (brief-<slug>.prompt.md) и который читает воркер:

## Каркас
- Роль: **<role>** — карточка ниже. Первым делом прочитай память `Teammates/<Роль>/Memory.md`.
- Прочитай карту репо `<repo>/CLAUDE.md`; менял топологию — обнови её тем же ходом.
- Прочитай конституцию `<путь>` и работай по ней.
- В начале — `git log --oneline -8` и `git status`.
- Делай сам: субагентов не поднимай. Всё, что не названо в брифе, — вне границ.
- Свой подпроцесс жди в этом же ходе: после выхода тебя никто не разбудит.
- Отчёт — `<repo>/scratchpad/report-<slug>.md`, привяжи его к карточке.
- В конце обнови память роли точечно; грабля ≥ 2 раз — в код, гейт или карту, не в память.
- Финальный отчёт — канал подставляет запускатель по движку: Claude — SendMessage на имя штаба **<имя из файла состояния штаба>**, остальные движки — секция в инбокс штаба через свой адаптер.
## Роль
<тело карточки роли>
## Бриф
<тело брифа>

Запуск через запускатель:

run-teammate --role web --brief <repo>/scratchpad/brief-<slug>.md --card <id> --model opus

Запуск вручную (fish внутри tmux; для Sonnet-механики — CLAUDE_CODE_EFFORT_LEVEL=medium в окружении процесса: флаг CLI --effort у нас его не перебивал, проверяли по транскриптам):

tmux new-session -d -s job-x 'claude -p --dangerously-skip-permissions --model claude-opus-5-5 \
  --settings \'{"crossSessionInbound":"accept"}\' "Прочитай <путь>.prompt.md и выполни его целиком." \
  2>&1 | tee /tmp/tmux-job-x.log; echo "EXIT=$pipestatus[1]" | tee -a /tmp/tmux-job-x.log; exec fish'

Сторож (в фоне штаба, окно ≤ 10 минут, потом перевесить):

t=0; until grep -Eq '^EXIT=-?[0-9]+[[:space:]]*$' /tmp/tmux-job-x.log || [ $t -ge 560 ]; do sleep 20; t=$((t+20)); done

Карточка решения:

{"id":"site-og-v2","type":"approve","owner":"max",
 "question":"OG-карточки v2 готовы на превью: новый шрифт, EN-заголовки.\n\nда → выкатываю на сайт; нет → остаётся v1",
 "default":"да","cost":"30 мин web-воркера, обратимо","artifact":"~/Vibe/site/scratchpad/report-og-v2.md",
 "ball":{"holder":"max","ask":{"kind":"permit","yes":"выкатываю OG v2 и проверяю превью"}},
 "executor":{"role":"web","model":"sonnet"}}

Вопросы для адаптации

  1. Сколько у тебя параллельных проектов и где сходятся их файлы (домашняя папка, база заметок, монорепо)? Там живёт штаб.
  2. Какие подписки и CLI: Claude (Max/Pro), Codex, Grok, Gemini, ключи API? От этого зависят ярусы моделей и то, какие роли на каком движке могут жить.
  3. Что для тебя human-only? Составь список из пяти–семи действий, которые делаешь только сам. Всё остальное агенты делают по умолчанию.
  4. Ты один или с людьми? С людьми — реестр решений и инбокс становятся общими, роли получают владельцев.
  5. Есть ли локальное железо под локальные модели? Тогда часть фоновых задач уходит на ноль, но считай честно: 27B-модель с длинным контекстом занимает 30 ГБ, и на 64 ГБ она мешает всему остальному. Без железа фон живёт на Haiku за копейки.
  6. Где живут заметки и решения сейчас? Штабу нужна база, которую читает человек и куда агенты ходят по правам своей роли и движка (Obsidian-vault подходит идеально): там же будут карточки ролей и их память.
  7. Какой ритм: работаешь днём и хочешь, чтобы ночью что-то происходило? Тогда launchd/cron-джобы с теми же брифами и отчётами и очередь команды в тихие часы.
  8. Какие правила твой агент уже нарушил дважды? Это первые кандидаты в гейты.

Нюансы и грабли

  • Headless-сессия завершается, как только перестаёт звать инструменты. Воркер, закончивший ход фразой «жду завершения рендера», просто вышел. Ждать можно только циклом в оболочке с таймаутом — правило стоит в каркасе каждого брифа.
  • Лог headless-воркера пуст до самого конца. Ноль байт через две минуты — не смерть; смерть — это отсутствие процесса. Сторож смотрит и на лог, и на tmux.
  • Отчёт в шаблонное имя сессии — отчёт в никуда. Поэтому имя штаба подставляет запускатель из файла состояния, а не автор брифа.
  • pkill -f <скрипт> убивает tmux-сервер, если строка совпала с его аргументами. Перед любым pkill — pgrep глазами.
  • Общий репозиторий и параллельные воркеры — чужие файлы уезжают в коммит и в деплой. Сначала инбокс и git status, потом сборка; в одно дерево — по одному писателю.
  • --fresh перезаписывает состояние роли. Две инстанции одной роли — вторую поднимай без роли или восстанавливай id вручную.
  • Ctrl+Z — не выход. Штаб, остановленный Ctrl+Z, остаётся живым процессом и держит лок «одна HQ». Новый запуск честно принимает себя за дубль и не работает. Лечение — завершить замороженную копию вместе с её осиротевшим сторожем: когда старый процесс мёртв, а возобновляется та же сессия, лок возвращается штатно.
  • Дубль штаба рождал сам CLI. Выход при живом мониторе предлагал «увести работу в фон и выйти»: разговор форкался в фоновую копию, и монитор переезжал в неё. Девять дней почти каждое утро рядом с живым штабом работала его копия с тем же контекстом. Решение в три слоя: обёртка выключает фоновый режим для процесса штаба, хук старта берёт лок, печатает стоп второй копии и не даёт ей переписать состояние основной, хук промпта блокирует фоновую копию. Вторую интерактивную копию эти слои не запрещают, а предупреждают — работать она технически может. Автоматически ничего не убиваем: показать, а не пристрелить.
  • Воркеры печатают секреты, не желая того. docker compose config раскрывает переменные, отладочный echo показывает токен, и значение уезжает в транскрипт, логи и память. Гард до команды и детектор после — раздел «Гейты».
  • launchd, TCC и уведомления macOS. Фоновые джобы launchd упираются в две системы. Первая показывает «может работать в фоне» по имени запускаемого файла и повторяет это при каждом пересканировании папки агентов, а пересканирование запускает любое изменение в ней. Вторая, доступ к папкам, считает ответственным сам процесс джобы, а не то, что он запускает. Решение — все 36 наших джоб стартуют через симлинки на один маленький бинарь-лаунчер: он пересылает сигналы и отдаёт код ребёнка, а грант доступа к папке — один на всех. Пересобирать лаунчер нельзя: новая подпись — новый грант и новая пачка уведомлений.
  • Итоги легко начать дублировать в мессенджер. Бот под рукой, и слать туда сводки удобно, но второй канал без спроса превращается в шум: человек и так видит итоги в карточках. 12 октября 2026 правило записали в карточку штаба: канал итогов — карточка, бот — только по просьбе человека или в ответ на задачу оттуда.
  • Модель в коде — спрятанное решение. С конца сентября по начало октября модели в реестре менялись четыре раза: штаб переехал с Fable на Opus 5.5, снят Opus 5, Sonnet 5 заменён на 5.5, Sol переехал на новую версию. Там, где id жил в реестре, смена была одной строкой; там, где был зашит в скрипт или текст, — правкой по файлам, которую легко недоделать. Этот блюпринт сам был таким местом: его v1 назывался по модели штаба.
  • Автообновление плагинов стирает локальные патчи. Всё, что патчил в кэше плагина, — записать в память с путём к оригиналу и проверкой после апдейта.
  • Цена зависит от длины входа. У части моделей ставка растёт, когда вход длиннее порога, и пороги у вендоров и моделей разные; у подписок свои условия. Проверяй тариф конкретной модели на дату сборки. Вывод тот же: брифы короткие, resume только при реальной нужде, толстую историю не таскать.
  • Второй агент подтверждает вывод первого — это ещё не факт. Согласие — тоже утверждение: принимаем после той же сверки, на чём держится и что сделало бы его неправдой.
  • Карточка без дефолта и «подтвердить» без цены — работа переложена на человека; такие карточки быстро перестают читать.
  • Своё и чужое. Содержимое закрытых спейсов, чатов и папок клиентов не переносится в другие контуры ни пересказом, ни намёком; наружу идёт только своё. Один воркер для всех проектов — самый частый способ это нарушить.

Масштабирование

  • Один воркер → флот. Как только джоб больше двух в день — запускатель, сторожа по одному на джобу, job-* убивать после сбора результата, dev-* не трогать.
  • Роли. Когда один и тот же жанр повторяется (сайт, продукт, контент, продовые инциденты), заводи роль карточкой с памятью: грабли перестают повторяться.
  • Дашборд. Реестр решений, нити, очередь команды, инбокс, журнал, здоровье сервисов — одна локальная страница; телефон — мост в мессенджере.
  • Другие движки. Сначала воркеры по брифу через тот же запускатель, потом роли с несколькими движками в platforms. Долгоживущую главную сессию Codex с курсором инбокса и «тычком» очереди мы построили 1 сентября и свернули 16-го: за две недели человек ни разу не написал в её канонический тред, зато открыл 22 прямые нити, а курсор отставал на шесть дней. Живое — прямые нити человека и append-only лента от штаба; доставлено = ответный след.
  • Локальные модели. Фоновые вызовы — память, классификация, сжимка — можно увести на локальный сервер, когда модель помещается в память рядом с работой; до тех пор их держит дешёвая облачная модель, а облако посильнее остаётся для суждения.
  • Ночная смена. Launchd/cron-джобы с теми же брифами: дайджесты, вотчеры, бэкапы, синк заметок, утренняя и вечерняя очередь команды; их результаты линкуются в дневную ноту тем же ходом.

Выходные артефакты

Что coding agent собирает вместе с тобой по этому Blueprint:

  • Карточка штаба с правилами и глобальный CLAUDE.md с механикой.
  • Карта первого репозитория.
  • Папка ролей в базе заметок: две-три карточки и пустая Memory.md у каждой.
  • models.json с алиасами моделей.
  • Запускатель, который пишет каркас протокола, и шаблон брифа-тела.
  • pending-decisions.json и скрипты карточек с мячом и видом запроса.
  • Инбокс-файл, один Monitor штаба на него и первый Stop-гейт — «развилка в чате».
  • Конституция v0.1 на пять статей, первая — список human-only; правится только твоим словом.
  • Первая handoff-нота, чтобы завтрашний штаб начал не с нуля.