Для кого

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

Blueprint: AI Team on Fable + Codex

Status: living. Так работает команда из одного человека и нескольких десятков AI-сессий в день с лета 2026: Claude Fable 5.1 как штаб, Opus/Sonnet как исполнители, Codex как второй контур. Всё ниже — из практики, включая грабли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура

Человек
  │  чат + карточки решений (дашборд) + мобильный мост
  ▼
HQ — Claude Code, Fable 5.1, effort max, бесконечная сессия через resume
  │  пишет брифы, читает отчёты, ведёт реестр решений, память, handoff
  ├──► Воркеры Claude — headless `claude -p` в tmux, Opus 5 / Sonnet 5
  │      роль + память роли + карта репо → бриф → отчёт → SendMessage в HQ
  ├──► Codex-контур — `codex exec -m astra|sol` в tmux (воркеры) + Codex-Main (второе мнение)
  │      бриф-файл → отчёт-файл → строка в инбокс HQ
  └──► Наблюдатели — Monitor на инбокс-файл, сторожа джоб, launchd-джобы
Общая земля (читают все): база заметок · репозитории с CLAUDE.md-картой ·
инбокс-файл · реестр решений · журнал команды · конституция

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

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

Роли. У каждой роли — папка с MEMORY.md (грабли, факты, решения человека) и state.json (id последней сессии, репозиторий). Запуск resume-first только когда контекст роли реально нужен (многоходовая задача, знание кодовой базы); короткая самодостаточная задача — свежая сессия, толстую историю не таскаем. Чем роль отличается от одноразового воркера и когда её заводить — раздел «Named teammates и обычные воркеры» ниже.

Codex-контур. Воркер Codex — codex exec в tmux по тому же протоколу: бриф-файл, отчёт-файл, маркер выхода. Пуш в штаб — маленький скрипт, который дописывает секцию в инбокс-файл, а Monitor штаба на этот файл будит HQ. Обратно — скрипт, который кладёт задачу в инбокс Codex-Main и тычет его очередь. Принято ≠ выполнено: завершение — это сдвинутый курсор и отчёт-артефакт.

Реестр решений. 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: грабли, факты, решения человека по её жанру. Роль обновляет память сама в конце задачи, штаб дописывает по отчётам. Это не дневник, а список «что я знаю, чего нет ни в коде, ни в брифе»: где лежат бэкапы прода, какой проект в облаке правильный, что человек запретил навсегда.
Состояние. state.json: id последней сессии, репозиторий, дата, последняя задача. Оно даёт resume: следующая задача по той же нити продолжает сессию с контекстом кодовой базы и предыдущих ходов, а не начинает знакомство заново.
Владение нитью. Континуитет исполнителя: кто начал работу по проекту, тому и следующая задача по нему, даже если по жанру напрашивается другая роль. Смена — с записанной причиной и handoff’ом: статус, артефакты, открытые риски, следующий ход. Так у продукта появляется «свой инженер», который помнит, почему сделали именно так.
Адрес. Штаб обращается к роли по имени через запускатель (--role web --brief …), а бриф первой строкой говорит «роль такая-то, прочитай свою память». Люди в команде тоже знают адрес: «это к ops».

	Воркер	Named teammate
Живёт	одну задачу	нить из многих задач
Контекст	весь в брифе	бриф + память роли + сессия
Память	нет: журнал и артефакты	`MEMORY.md` + `state.json`
Запуск	всегда свежая сессия	resume-first, свежая когда контекст не нужен
Модель	по жанру задачи	по роли, бриф может перебить
Отвечает за	результат задачи	нить проекта, карту репо, каноны
Когда	до получаса, самодостаточно	повторяющийся жанр, кодовая база, долгие нити

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

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

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

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

Роль и вендор. Роль привязана к жанру, не к движку. Она может жить на Claude или на Codex (у нас curator, владелец энциклопедий и деков, работает на Codex): тот же принцип, память и состояние, другой запуск и другой канал отчёта. Запускатель читает провайдера из описания роли, штаб этой разницы не замечает.

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

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

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

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

# .codex/agents/scout.toml — дешёвая разведка, только чтение
name = "scout"
description = "Read-only разведчик по кодовой базе на дешёвой модели."
model = "gpt-5.6-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), а не по словам субагента о себе.

Что мы знаем о цене и качестве. Ночной бенчмарк 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 — что изменилось с прошлого визита. Последняя: «обнови память роли, напиши отчёт, отправь его в сессию <реальное имя штаба>». Шаблонное имя штаба = отчёт в никуда.
Модель явно, effort явно. Штаб — максимум. Sonnet-механике — средний effort через переменную окружения в команде запуска. Молчаливый фоллбэк на другую модель запрещён: не получилось запустить — скажи.
Всё дольше тридцати секунд — в tmux. Не foreground (блокирует ход), не фоновая оболочка (умирает с сессией). Сторож — цикл until с таймаутом на файл лога, по одному на джобу; общий наблюдатель на много джоб слепнет.
Артефакты — в постоянных местах. Отчёты в scratchpad/ репозитория, не в /tmp: ребут стирает временные папки вместе с историей работы.
Один общий репозиторий ≠ параллельные воркеры. Перед сборкой и деплоем — инбокс и git status: чужие незакоммиченные файлы уезжают паровозом. Если человек сам сидит в этом репозитории интерактивной сессией — воркера не поднимать, задачу отдать ей.
Секреты — только в keychain и окружении. Никаких .env в коде, никаких ключей в отчётах, логах и коммитах. Скрипты берут ключи через хелпер, брифы напоминают «в лог не печатать».
Кодифицируем, а не запоминаем. Правило, сработавшее дважды, уходит в хук, гейт, скрипт или манифест процесса. Волатильное — модель, цена, путь, лимит — в конфиг, не в тело кода и промпта.
Обратимость по умолчанию. Бэкап до изменения, откат одним ходом. Необратимое — только по списку человека.
Слом предпосылки — не повод молчать. Одобренный подход упёрся в новый факт: замена обратима и цель та же — делаем и докладываем; сдвигается цель, деньги, люди или публичность — стоп и вопрос.
Синхрон вендоров. Каждая содержательная работа оставляет след, который читает вторая сторона: отчёт или коммит от Codex, дневник и журнал от штаба. В каждом брифе Codex — строка про след.

Workflow

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

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

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

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

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

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

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

Глобальный CLAUDE.md — кто ты, где что лежит, конвенции (tmux, секреты, коммиты), раздел «Оркестрация» с матрицей моделей, протоколом брифов и правилом человека. Это единственное место для механики оркестрации; дублирование в других файлах ловит дрейф.
Карты репозиториев — CLAUDE.md в корне каждого активного репозитория. Воркер стартует с cwd в репо и подхватывает карту сам; карты нет — первый воркер пишет её до задачи; поменял топологию — обновляет тем же ходом.
Роли — ~/.claude/teammates/<role>/MEMORY.md + state.json, плюс описание роли (кто, что умеет, какие инструменты) для агент-типа.
Запускатель — один скрипт: --role, --brief, --model, --effort, --cwd, --session; сам выбирает провайдера (Claude или Codex), resume или свежую сессию, пишет лог с маркером выхода, ретраит перегрузку. Руками собирать команду только для случаев, которые он не покрывает.
Брифы и отчёты — scratchpad/brief-<slug>.md и scratchpad/report-<slug>.md в репозитории задачи; scratchpad/ в .gitignore и в исключениях деплоя.
Реестр решений — pending-decisions.json + скрипты decision-add / decision-close с гейтами (уникальный id, дефолт, цена у «подтвердить», артефакт при закрытии) + дашборд с кнопками.
Инбокс-файл — markdown с секциями ## <источник> <дата время> — <тема>; писатели: мост из мессенджера, алерты продовых ботов, Codex, ответы по карточкам; штаб держит на нём один Monitor и помечает обработанные секции.
Журнал команды — хук пишет события «запуск / готово / стоп» с агентом, моделью и задачей в jsonl; Codex журналируется обёрткой; вьювер в дашборде.
Конституция — восемь коротких статей с «уликой» у каждой: последнее слово у человека (и единый список human-only); факт держится на источнике; обратимость по умолчанию; слом предпосылки — не повод молчать; есть артефакт — была работа; кодифицируем, а не запоминаем; контуры изолированы (закрытые аудитории не смешиваются); континуитет исполнителя (нить остаётся у того, кто её ведёт). Правится только словом человека, с версией и историей.
Мосты — мессенджер → инбокс (входящие с телефона), «отправить от моего имени» только через карточку-подтверждение с одноразовым токеном.
Наблюдатель памяти на Haiku 4.5 (дефолт) или на локальной модели: OpenAI-совместимый эндпоинт локального сервера, thinking выключен прокси, потому что фоновой сжимке он не нужен, а время режет в шесть раз. Локальный вариант окупается только на модели, которая помещается в память вместе с остальной работой.

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

Бриф (минимум):

# Бриф: <что сделать> (<кто попросил>, <дата>)
Роль: **<role>**. Первым делом прочитай свою память `~/.claude/teammates/<role>/MEMORY.md`.
Задача: <одним абзацем, с цитатой слова человека>.
Прочитай конституцию `<путь>` и работай по ней; карта репо — `<путь>/CLAUDE.md`.
Ты внутри tmux `job-<slug>-worker` — не трогать, лог не удалять. Подджобы — `job-<slug>-<шаг>-sub`, только свои.
Перед стартом: `git log --oneline -8 && git status --short`.
## Что сделать
1. … (границы, что НЕ трогать, критерии проверки, откат)
## Отчёт
`<repo>/scratchpad/report-<slug>.md`: … Обнови память роли. Последний шаг — SendMessage в сессию **<имя штаба>**.

Запуск воркера вручную (fish внутри tmux; для Sonnet-механики — префикс с effort):

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

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

until grep -q '^EXIT=' /tmp/tmux-job-x.log || [ $t -ge 560 ]; do sleep 20; t=$((t+20)); done

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

{"id":"site-og-v2","type":"approve","question":"да → выкатываю OG-карточки v2 на сайт; нет → остаётся v1",
 "default":"да","cost":"30 мин web-воркера, обратимо","artifact":"~/Vibe/site/scratchpad/report-og-v2.md","owner":"max"}

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

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

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

Headless-сессия завершается, как только перестаёт звать инструменты. Воркер, закончивший ход фразой «жду завершения рендера», просто вышел. Ждать можно только циклом в оболочке с таймаутом — правило пишется в каждый бриф.
Лог headless-воркера пуст до самого конца. Ноль байт через две минуты — не смерть; смерть — это отсутствие процесса. Сторож смотрит и на лог, и на tmux.
Отчёт в шаблонное имя сессии — отчёт в никуда. Имя штаба берётся из списка сессий при написании брифа и вписывается буквально.
pkill -f <скрипт> убивает tmux-сервер, если строка совпала с его аргументами. Перед любым pkill — pgrep глазами.
Общий репозиторий и параллельные воркеры — чужие файлы уезжают в коммит и в деплой. Сначала инбокс и git status, потом сборка; в одно дерево — по одному писателю.
--fresh перезаписывает состояние роли. Две инстанции одной роли — вторую поднимай без роли или восстанавливай id вручную.
Автообновление плагинов стирает локальные патчи. Всё, что патчил в кэше плагина, — записать в память с путём к оригиналу и проверкой после апдейта.
Прайсинг вендоров различается по контексту. У OpenAI запросы длиннее 272K входа считаются вдвое за вход и в полтора раза за выход целиком; у Anthropic до 1M плоская ставка. Вывод: брифы короткие, resume только при реальной нужде, толстую историю не таскать.
Второй агент подтверждает вывод первого — это ещё не факт. Согласие — тоже утверждение: принимаем после той же сверки, на чём держится и что сделало бы его неправдой.
Карточка без дефолта и «подтвердить» без цены — работа переложена на человека; такие карточки быстро перестают читать.
Своё и чужое. Содержимое закрытых спейсов, чатов и папок клиентов не переносится в другие контуры ни пересказом, ни намёком; наружу идёт только своё. Один воркер для всех проектов — самый частый способ это нарушить.

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

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

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

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

Глобальный CLAUDE.md с разделом «Оркестрация» и списком human-only.
Карта первого репозитория.
Папка ролей с двумя-тремя ролями и пустой памятью.
Запускатель воркеров и шаблон брифа.
pending-decisions.json и скрипты добавления/закрытия карточек.
Инбокс-файл и один Monitor штаба на него.
Конституция v0.1 на пять статей — правится только твоим словом.
Первая handoff-нота, чтобы завтрашний штаб начал не с нуля.

Скачать .md Забрать агентом: /mcp