Для тех, кто ведёт несколько проектов в одиночку и хочет, чтобы 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) или на локальной, если есть железо.
- Тиммейты вне вендора: роль описана один раз карточкой в базе заметок, её память лежит рядом, и запускатель отдаёт одну и ту же роль любому движку из её списка.
- Реестр решений с мячом: любая развилка для человека — карточка с дефолтом и путём к артефакту, а не вопрос в чате, который утонет. Карточка знает, у кого сейчас ход и чего именно ждут от человека.
- Гейты дисциплины в коде: ответ без карточки, развилка в чате, работа руками штаба, мёртвый монитор инбокса, печать секретов — ловит хук, а не память модели.
- Память, которая переживает сессии и вендоров: карты репозиториев, память ролей, файловая память штаба, конституция команды.
- Правило синхрона: действия одного движка всегда видны другим через след в файлах.
Как применить
- Открой coding agent (Claude Code) в домашней директории или в корне своей базы заметок — штаб живёт там, где сходятся все проекты, а не внутри одного репозитория.
- Покажи ему этот Blueprint: «Собери мне AI-команду по этому Blueprint. Начни с раздела „Вопросы для адаптации“».
- Агент соберёт первый слой: карточку штаба с правилами, глобальный
CLAUDE.mdс механикой, карту первого репозитория, реестр моделей, запускатель воркеров, файл решений. Это день первый. - Неделя первая — привычка: каждая задача длиннее получаса уходит воркеру по брифу; штаб руками делает только то, где бриф дороже самой работы.
- Неделя вторая — роли и второй движок: заводишь две-три роли карточками в базе заметок, конституцию на пять–восемь статей, подключаешь Codex (или другой CLI) через тот же запускатель.
- Неделя третья — гейты: каждое правило, которое модель нарушила дважды, уезжает в хук.
Когда использовать
- Ты один, но проектов больше трёх, и они живут параллельно: сайт, контент, продукт, операционка.
- Ты платишь больше чем за один 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-файлах проекта и уезжают в репозиторий вместе с кодом.
Ключевые принципы
- Бриф — только тело. Задача, границы, дельта, след. Протокол — роль, память, карту репо, конституцию,
git log / status, путь отчёта, имя штаба, обновление памяти, кодификацию граблей — дописывает запускатель в промпт рядом с брифом. Повод: каркас вырос с 17 до 41 % брифа, и штаб каждый раз писал его заново. Строки протокола код печатает всегда — тело брифа их не гасит. - Модель явно, effort явно. Штаб — max, Opus-воркеры — high, Sonnet-механика — medium. Effort воркера задаётся явно (Opus — настройкой модели, Sonnet — переменной окружения его процесса), а переменная штаба не должна протечь в воркеров через tmux-сервер — запускатель её снимает. Молчаливый фоллбэк на другую модель запрещён: не получилось запустить — скажи.
- Всё дольше тридцати секунд — в tmux. Не foreground (блокирует ход), не фоновая оболочка (умирает с сессией). Сторож — цикл
untilс таймаутом на файл лога, по одному на джобу; общий наблюдатель на много джоб слепнет. - Артефакты — в постоянных местах. Отчёты в
scratchpad/репозитория, не в/tmp: ребут стирает временные папки вместе с историей работы. - Один репозиторий — один пишущий. Перед сборкой и деплоем — инбокс и
git status: чужие незакоммиченные файлы уезжают паровозом. Если человек сам сидит в этом репозитории интерактивной сессией — воркера не поднимать, задачу отдать ей. - Секреты — только в keychain и окружении. Никаких
.envв коде, никаких ключей в отчётах, логах и коммитах. Скрипты берут ключи через хелпер; гарды снижают риск печати, но не заменяют ограничения доступа (раздел «Гейты»). - Кодифицируем, а не запоминаем. Правило, сработавшее дважды, уходит в хук, гейт, скрипт или манифест процесса. Волатильное — модель, цена, путь, лимит — в конфиг, не в тело кода и промпта.
- Обратимость по умолчанию. Бэкап до изменения, откат одним ходом. Необратимое — только по списку человека.
- Слом предпосылки — не повод молчать. Одобренный подход упёрся в новый факт: замена обратима и цель та же — делаем и докладываем; сдвигается цель, деньги, люди, публичность или границы — стоп и вопрос.
- Синхрон движков. Каждая содержательная работа оставляет след, который читают другие: отчёт или коммит, дневная нота, журнал команды, файл текущего контекста для Codex. В каждом брифе Codex — строка про след.
- Второе мнение — по цене решения. Opus делает, Astra читает; три голоса — для необратимого решения или изменения того, как человек работает с системой; Grok — при расхождении первых двух.
- Канал итогов — карточка. Мессенджер — только по просьбе человека.
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"}}
Вопросы для адаптации
- Сколько у тебя параллельных проектов и где сходятся их файлы (домашняя папка, база заметок, монорепо)? Там живёт штаб.
- Какие подписки и CLI: Claude (Max/Pro), Codex, Grok, Gemini, ключи API? От этого зависят ярусы моделей и то, какие роли на каком движке могут жить.
- Что для тебя human-only? Составь список из пяти–семи действий, которые делаешь только сам. Всё остальное агенты делают по умолчанию.
- Ты один или с людьми? С людьми — реестр решений и инбокс становятся общими, роли получают владельцев.
- Есть ли локальное железо под локальные модели? Тогда часть фоновых задач уходит на ноль, но считай честно: 27B-модель с длинным контекстом занимает 30 ГБ, и на 64 ГБ она мешает всему остальному. Без железа фон живёт на Haiku за копейки.
- Где живут заметки и решения сейчас? Штабу нужна база, которую читает человек и куда агенты ходят по правам своей роли и движка (Obsidian-vault подходит идеально): там же будут карточки ролей и их память.
- Какой ритм: работаешь днём и хочешь, чтобы ночью что-то происходило? Тогда launchd/cron-джобы с теми же брифами и отчётами и очередь команды в тихие часы.
- Какие правила твой агент уже нарушил дважды? Это первые кандидаты в гейты.
Нюансы и грабли
- 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-нота, чтобы завтрашний штаб начал не с нуля.