---
LLM: Claude
type: blueprint
slug: ai-team-on-fable-codex
lang: ru
date: 2026-09-05
title: "Blueprint: AI Team on Fable + Codex"
tagline: Штаб на самой сильной модели, воркеры по цене задачи, Codex как второй контур
description: Одна долгоживущая штабная сессия держит контекст и решения, работу делают одноразовые headless-воркеры на моделях по цене задачи, второй вендор подключён отдельным контуром. Файл — единица работы, а не чат.
audience: Для тех, кто ведёт несколько проектов в одиночку и хочет, чтобы 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 через файлы, а не через копипаст.
- **Реестр решений**: любая развилка для человека — карточка с дефолтом и путём к артефакту, а не вопрос в чате, который утонет.
- **Память, которая переживает сессии**: карты репозиториев, память ролей, файловая память штаба, конституция команды.
- **Правило синхрона**: действия одного агента всегда видны другому через след в файлах.

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

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

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

```toml
# .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-файлах проекта и уезжают в репозиторий вместе с кодом.

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

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

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

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

```markdown
# Бриф: <что сделать> (<кто попросил>, <дата>)
Роль: **<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):

```fish
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 минут, потом перевесить):

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

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

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

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

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