--- LLM: Claude type: blueprint slug: ai-team-across-engines lang: ru date: 2026-09-05 title: "Blueprint: AI Team Across Engines" tagline: Штаб на сильной модели, воркеры по цене задачи, роль описана один раз и работает на любом движке description: Одна долгоживущая штабная сессия держит контекст и решения, работу делают headless-воркеры на моделях по цене задачи, роли описаны один раз и работают на Claude, Codex, Grok и Gemini. Файл — единица работы, а не чат; дисциплину держит код. audience: Для тех, кто ведёт несколько проектов в одиночку и хочет, чтобы AI-сессии не умирали вместе с контекстом --- # Blueprint: AI Team Across Engines > **Status: living · v2.0, 13 октября 2026.** Так работает команда из одного человека и нескольких сотен AI-запусков в неделю: штаб на Claude Opus 5.5, исполнители на Opus и Sonnet, а Codex, Grok и Gemini — каждый на своём жанре. Для масштаба одна неделя, 5 – 11 октября 2026: 260 запусков тиммейтов, 22 роли в работе на четырёх движках, 189 закрытых задач. Всё ниже — из практики, включая грабли. До v2 блюпринт назывался «AI Team on Fable + Codex»: штаб тогда жил на Fable, а движков было два. Ты открываешь Claude Code, ставишь самую сильную модель и делаешь в одной сессии всё подряд: код, тексты, ресёрч, переписку. Через день контекст забит, решения растворились в чате, половина токенов ушла на рутину, которую сделала бы модель втрое дешевле. Рядом лежат подписки Codex и других движков, но инструменты живут в разных мирах и не знают, что делает другой. Сессия умирает — и вместе с ней всё, что она «помнила». Этот Blueprint описывает другую модель: **одна долгоживущая штабная сессия на сильной модели держит контекст и решения, работу делают одноразовые headless-воркеры на моделях по цене задачи, роли описаны один раз и работают на любом подключённом движке, а всё, что важно, живёт в файлах, а не в чатах.** Штаб не исполнитель, а менеджер. Файл — единица работы. Человек говорит последнее слово по короткому списку необратимых действий. Дисциплину держит код, а не обещания модели. ## Что ты получишь - **HQ-сессия**, которая не умирает: живёт через resume, при старте получает блок «состояние мира» и продолжает с того места, где остановилась вчера. Штаб один: штатный запуск отключает фоновые форки, а стартовый хук распознаёт дубль и бережёт состояние основной сессии. - **Флот воркеров**: каждая задача — отдельный headless-запуск в tmux по брифу-файлу, с отчётом-файлом, маркером выхода и сторожем; модель выбирается явно под задачу. - **Матрица моделей**: штаб на Opus 5.5 с максимальным effort, содержательная работа на Opus 5.5 (effort high), механика на Sonnet 5.5 со средним effort. У Codex та же пара ярусов: Astra для содержательного, Sol для механики. Grok — третий голос в спорах и механика по точному брифу, Gemini — пока только механика. Фоновые задачи (например, память между сессиями) — на дешёвой облачной модели (у нас наблюдатель на Haiku 4.5) или на локальной, если есть железо. - **Тиммейты вне вендора**: роль описана один раз карточкой в базе заметок, её память лежит рядом, и запускатель отдаёт одну и ту же роль любому движку из её списка. - **Реестр решений с мячом**: любая развилка для человека — карточка с дефолтом и путём к артефакту, а не вопрос в чате, который утонет. Карточка знает, у кого сейчас ход и чего именно ждут от человека. - **Гейты дисциплины в коде**: ответ без карточки, развилка в чате, работа руками штаба, мёртвый монитор инбокса, печать секретов — ловит хук, а не память модели. - **Память, которая переживает сессии и вендоров**: карты репозиториев, память ролей, файловая память штаба, конституция команды. - **Правило синхрона**: действия одного движка всегда видны другим через след в файлах. ## Как применить 1. Открой coding agent (Claude Code) **в домашней директории или в корне своей базы заметок** — штаб живёт там, где сходятся все проекты, а не внутри одного репозитория. 2. Покажи ему этот Blueprint: «Собери мне AI-команду по этому Blueprint. Начни с раздела „Вопросы для адаптации“». 3. Агент соберёт первый слой: карточку штаба с правилами, глобальный `CLAUDE.md` с механикой, карту первого репозитория, реестр моделей, запускатель воркеров, файл решений. Это день первый. 4. Неделя первая — привычка: каждая задача длиннее получаса уходит воркеру по брифу; штаб руками делает только то, где бриф дороже самой работы. 5. Неделя вторая — роли и второй движок: заводишь две-три роли карточками в базе заметок, конституцию на пять–восемь статей, подключаешь Codex (или другой CLI) через тот же запускатель. 6. Неделя третья — гейты: каждое правило, которое модель нарушила дважды, уезжает в хук. ## Когда использовать - Ты один, но проектов больше трёх, и они живут параллельно: сайт, контент, продукт, операционка. - Ты платишь больше чем за один AI-инструмент (Claude, Codex, Grok, Gemini) и хочешь, чтобы они работали одной командой, а не по очереди. - Тебе важны решения и история: что решили, почему, где артефакт, — а не только результат. - Ты готов принять правило «файл — единица работы» и писать брифы вместо устных поручений в чате. ## Когда **не** использовать - Один проект, один репозиторий, работа линейная — хватит одной сессии с хорошим `CLAUDE.md`. - Ты не готов держать tmux, скрипты запуска, хуки и файлы состояния: этот Blueprint про операционку, а не про «умный промпт». - Нужен полностью автономный агент без человека в петле: здесь человек в петле по выбору, а не потому, что не доросли. ## Ключевая идея **Штаб — менеджер, не исполнитель.** Модель штаба дорога не токенами, а контекстом: каждая рутина, сделанная её руками, вытесняет из окна то, ради чего она нужна, — решения, историю, суждение. Поэтому граница записана матрицей «сам или агент». Сам штаб ведёт реестр решений, пишет брифы, принимает отчёты и делает правку в пару вызовов, когда исполнитель ясен. Агенту уходит любой новый артефакт для человека, код дальше одной строки, деплой, ресёрч дольше двух поисков и любая работа в репозитории, у которого есть владелец нити. Исключение — только вслух, фразой «сам: <причина>». **Модель — по задаче, не по привычке.** Содержательная работа (код-дизайн, продукт, деньги, ресёрч с выводами) — Opus 5.5 с effort high. Механика по точному чек-листу (смоуки, деплой по плану, переносы файлов, перегенерации по готовым промптам) — Sonnet 5.5 со средним effort. Штаб — Opus 5.5 с максимальным effort, потому что его ошибка стоит дороже всех. У других движков то же деление по ярусам. Модель задаётся в команде запуска явно, её id живёт в одном реестре; молчаливая подмена запрещена. **Файлы, не чаты.** Бриф — файл. Отчёт — файл. Решение — карточка с путём к артефакту. Правило команды: «есть артефакт — была работа; расплывчато — не сделано». Чат — это шум, который сгорает при компакции; файл переживает и сессию, и модель, и вендора. **Роль одна, движков много.** Роль привязана к жанру, а не к движку: она описана один раз, и Claude, Codex, Grok и Gemini получают одну и ту же. Второй движок нужен не как запасной штаб, а как другая голова: ревью, независимая критика, длинные генерации, дешёвая механика. Требование к каждому одно: он должен видеть, что сделали другие. Значит, обмен идёт через файлы общего формата — брифы, отчёты, карточки, — а не через копипаст; что именно каждому движку можно читать, задаётся отдельно. **Второе мнение — по цене решения.** По умолчанию — «Opus делает, Astra читает»: исполнитель на одном вендоре, ревьюер на другом. Полный консилиум из трёх голосов — только когда решение необратимо или меняет то, как человек работает с системой. Третий голос (у нас Grok) зовут, когда первые два разошлись, а не ради кворума. **Последнее слово — у человека, но список короткий.** Не «спрашивай на всё», а один явный список: отправка сообщений людям, публикация, платежи, деплой новых систем, миграции продовой базы, продовая конфигурация, удаление данных. Всё остальное — по умолчанию делаем и докладываем. Одно названное исключение из «отправки людям»: регулярные рубрики по расписанию (у нас — недельная рубрика в двух спейсах Team2Team по launchd) уходят без человека в момент поста, но по заранее записанному слову человека на эту рубрику, этот спейс и этот ритм, Опенер у рубрики шаблонный; если за неделю есть находки, дайджест пишет LLM без единого инструмента, а условия отправки, адрес и сам сетевой вызов держит скрипт-обёртка в пределах заранее одобренных рубрики, аудитории и расписания. Исключение живёт в документе, а не в голове: без записи это нарушение. **Дисциплина — в коде, а не в обещаниях.** Модель, которая сказала «больше так не буду», после компакции не помнит обещания. Правило, нарушенное дважды, становится хуком: он видит ход штаба и останавливает его или хотя бы напоминает, пока нарушение не исправлено или не названо вслух. Подробно — раздел «Гейты дисциплины в коде». ## Архитектура ``` Человек │ карточки решений (дашборд) + чат + мобильный мост ▼ HQ — Claude Code, Opus 5.5, effort max, одна бесконечная сессия через resume │ пишет брифы, читает отчёты, ведёт реестр решений, память, handoff ├──► Запускатель: карточка роли + бриф → движок и модель из реестра │ ├─ Claude — `claude -p` в tmux, Opus 5.5 / Sonnet 5.5 │ ├─ Codex — `codex exec` в tmux, Astra / Sol │ ├─ Grok — третий голос и механика по точному брифу │ └─ Gemini — только механика по точному брифу │ бриф → отчёт-файл → EXIT в лог → сообщение или секция в инбокс HQ ├──► Нити Codex у человека — прямо в базе заметок; HQ → Codex — лента-файл └──► Наблюдатели — Monitor на инбокс, сторожа джоб, launchd-джобы, Stop-гейты Общая земля — формат один, доступ по роли и движку: карточки ролей · брифы, отчёты, карты репозиториев · конституция; база заметок, инбоксы, реестр решений и журнал — по правам конкретной роли ``` **HQ.** Одна интерактивная сессия Claude Code на Opus 5.5. Рестарт — команда-обёртка: она делает resume живого id из файла состояния и сразу подаёт стартовое сообщение «прочитай правила и состояние мира». При каждом старте, resume и компакции хук кладёт в контекст блок «состояние мира»: последний handoff, решения со сроком, непрочитанные секции инбокса, состояние ролей, осиротевшие процессы, путь и хеш карточки с правилами штаба. После компакции штаб перечитывает свою карточку целиком: саммари помнит, что правила читали, но не сами правила. Раз в день-два HQ пишет handoff-ноту: что горячо, что ждёт человека, что делать первым. Штаб один: обёртка отключает фоновые форки, стартовый хук берёт лок, и вторая копия получает стоп первой строкой и не трогает состояние основной — почему это пришлось кодировать и где у защиты границы, рассказано в граблях. **Воркеры.** Каждая задача — tmux-сессия `job-` с 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//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. ```toml # .codex/agents/scout.toml — дешёвая разведка, только чтение name = "scout" description = "Read-only разведчик по кодовой базе на дешёвой модели." model = "gpt-6.1-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`), а не по словам субагента о себе. С 01.10.2026 алиас `sol` у нас указывает на `gpt-6.1-sol`; на новой модели зонд не повторяли. **Что мы знаем о цене и качестве.** Ночной бенчмарк 06.09.2026 на наших задачах: там, где источник лежит перед моделью (сверка фактов, счёт по данным), Opus, Astra и Sol дали одинаковый максимум во всех повторах, а содержательная задача на суждение (месяц транскриптов: обещания, сквозные сюжеты, решение) развела их — Opus 0.865, Astra 0.761, Sol 0.698 при цене прогона $0.77 / $1.01 / $0.39. Вывод тот же, что у пары Opus/Sonnet: механику отдавать дешёвой модели без потери, суждение оставлять сильной. **Где здесь экономия, а где нет.** Субагенты в сумме тратят больше токенов, чем одна сессия: у каждого свой контекст и свои вызовы инструментов. Выигрыш даёт не параллельность, а дешёвая модель на дешёвой роли: explorer на Sol read-only, worker на средней модели, судья или родитель на сильной. Классическая ошибка — поставить сильную модель родителю и ничего не задать детям: они молча унаследуют её, и «экономная» схема выйдет дороже одной сессии. **Как выбрать слой.** Слой 1 — когда задача самодостаточна и её можно описать брифом: штаб видит модель в команде запуска, в журнале команды и в карточке; это наш дефолт. Слой 2 — когда одна сессия Codex сама разбивает работу на разведку и исполнение и ей нужна параллельность внутри задачи; тогда модели детей фиксируются в TOML-файлах проекта и уезжают в репозиторий вместе с кодом. ## Ключевые принципы 1. **Бриф — только тело.** Задача, границы, дельта, след. Протокол — роль, память, карту репо, конституцию, `git log / status`, путь отчёта, имя штаба, обновление памяти, кодификацию граблей — дописывает запускатель в промпт рядом с брифом. Повод: каркас вырос с 17 до 41 % брифа, и штаб каждый раз писал его заново. Строки протокола код печатает всегда — тело брифа их не гасит. 2. **Модель явно, effort явно.** Штаб — max, Opus-воркеры — high, Sonnet-механика — medium. Effort воркера задаётся явно (Opus — настройкой модели, Sonnet — переменной окружения его процесса), а переменная штаба не должна протечь в воркеров через tmux-сервер — запускатель её снимает. Молчаливый фоллбэк на другую модель запрещён: не получилось запустить — скажи. 3. **Всё дольше тридцати секунд — в tmux.** Не foreground (блокирует ход), не фоновая оболочка (умирает с сессией). Сторож — цикл `until` с таймаутом на файл лога, по одному на джобу; общий наблюдатель на много джоб слепнет. 4. **Артефакты — в постоянных местах.** Отчёты в `scratchpad/` репозитория, не в `/tmp`: ребут стирает временные папки вместе с историей работы. 5. **Один репозиторий — один пишущий.** Перед сборкой и деплоем — инбокс и `git status`: чужие незакоммиченные файлы уезжают паровозом. Если человек сам сидит в этом репозитории интерактивной сессией — воркера не поднимать, задачу отдать ей. 6. **Секреты — только в keychain и окружении.** Никаких `.env` в коде, никаких ключей в отчётах, логах и коммитах. Скрипты берут ключи через хелпер; гарды снижают риск печати, но не заменяют ограничения доступа (раздел «Гейты»). 7. **Кодифицируем, а не запоминаем.** Правило, сработавшее дважды, уходит в хук, гейт, скрипт или манифест процесса. Волатильное — модель, цена, путь, лимит — в конфиг, не в тело кода и промпта. 8. **Обратимость по умолчанию.** Бэкап до изменения, откат одним ходом. Необратимое — только по списку человека. 9. **Слом предпосылки — не повод молчать.** Одобренный подход упёрся в новый факт: замена обратима и цель та же — делаем и докладываем; сдвигается цель, деньги, люди, публичность или границы — стоп и вопрос. 10. **Синхрон движков.** Каждая содержательная работа оставляет след, который читают другие: отчёт или коммит, дневная нота, журнал команды, файл текущего контекста для Codex. В каждом брифе Codex — строка про след. 11. **Второе мнение — по цене решения.** Opus делает, Astra читает; три голоса — для необратимого решения или изменения того, как человек работает с системой; Grok — при расхождении первых двух. 12. **Канал итогов — карточка.** Мессенджер — только по просьбе человека. ## Workflow **Утро.** Ещё до человека скрипт кладёт в инбокс утреннюю очередь команды, и штаб поднимает по ней воркеров, если позволяет лимит. Рестарт штаба: обёртка подаёт стартовое сообщение, хук показывает handoff, карточки со сроком, инбокс, роли, сирот в tmux и карточки, где мяч завис. Одно-два действия на разгребание (перевзвести монитор инбокса, убить сирот), потом задачи. **Задача пришла.** Штаб решает, сам или агент, — по матрице. Потом — чья это нить: кто её ведёт (отчёты, коммиты, память ролей, контекст Codex), тому и следующая задача, если человек не сказал иное. Карточка задачи, бриф-тело с контекстом, границами и критериями проверки, запуск с привязкой к карточке, сторож. Дорогая ошибка — сначала план. Развилка — карточка с дефолтом тем же ходом. **Отчёт пришёл.** Штаб проверяет факты, которые расходятся с его контекстом (дата имени файла — не дата события; «сделано» без пути — не сделано). Результат для рук человека — мяч человеку с видом запроса; остальное закрывает только с артефактом. Паспорт нити — тем же ходом. Дописывает дневник и контекст для Codex. Убивает tmux-джобу после сбора результата. **Человек ответил по карточкам.** Ответ → действие (закрыть в лог или запустить воркера), реплика в тред карточки, мяч — тому, у кого теперь ход, отметка «обработано» в инбоксе. Ответ карточку не закрывает — закрывает штаб артефактом или человек своим «да». **Вечер.** Handoff-нота: горячее, что ждёт человека, что делать первым завтра. Вечерняя очередь команды. Компакция контекста — по самочувствию, дрейф начинается раньше потолка. **Неделя.** Разбор всего, что лежит без движения дольше двух недель, ревью памяти ролей, обходы гейтов и метрика «сам или агент»: где штаб руками делал работу агента. Правила, которые пора кодифицировать. ## Компоненты решения - **Карточка штаба** — правила штаба для любой платформы: миссия, что не делегируется, канал выборов, исполнители, континуитет, консилиумы, отчётность. Лежит в базе заметок рядом с карточками ролей. - **Глобальный `CLAUDE.md` и скиллы** — механика: команды, флаги, пути, пороги. Правила штаба здесь не повторяются — только ссылка на карточку: двойное ведение уже ловило дрейф. Скиллы грузятся по требованию — перед брифом, перед карточкой. - **Карты репозиториев** — `CLAUDE.md` в корне каждого активного репозитория. Воркер стартует с cwd в репо и подхватывает карту сам; карты нет — первый воркер пишет её до задачи; поменял топологию — обновляет тем же ходом. - **Роли** — карточка и `Memory.md` в базе заметок, `state.json` у агента; синк-скрипт генерирует из карточек файлы под движки. - **Реестр моделей** — `models.json`: алиас, id, движок, способности движка. Реестр един для запуска воркеров и выбора исполнителя в дашборде; модель самого штаба пока закреплена отдельно, в его обёртке. - **Запускатель** — один скрипт: `--role`, `--brief`, `--model`, `--effort`, `--card`, `--mode plan|exec`, `--fresh`, `--dry-run`. Читает карточку роли и проверяет `platforms`, выбирает движок по алиасу, resume или свежую сессию, пишет каркас протокола рядом с брифом, лог с маркером выхода, событие в журнал команды и попытку в карточку, ретраит перегрузку. Руками собирать команду — только для случаев, которые он не покрывает. - **Брифы и отчёты** — `scratchpad/brief-.md` (тело), `brief-.prompt.md` (каркас, его пишет запускатель) и `scratchpad/report-.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-*` и дашборд — имена наших собственных скриптов, и агенту предстоит написать их аналоги у тебя. Бриф — только тело: ```markdown --- decision: <ссылка на карточку> --- # Бриф <роль>: <что сделать> Карточка: <ссылка>. Что решил человек: «<цитата>». ## Что сделать 1. … (критерии проверки, откат) ## Границы - что НЕ трогать; что требует слова человека ## След Отчёт: `/scratchpad/report-.md`. К карточке привязать: … ``` Каркас, который запускатель пишет рядом (`brief-.prompt.md`) и который читает воркер: ```markdown ## Каркас - Роль: **** — карточка ниже. Первым делом прочитай память `Teammates/<Роль>/Memory.md`. - Прочитай карту репо `/CLAUDE.md`; менял топологию — обнови её тем же ходом. - Прочитай конституцию `<путь>` и работай по ней. - В начале — `git log --oneline -8` и `git status`. - Делай сам: субагентов не поднимай. Всё, что не названо в брифе, — вне границ. - Свой подпроцесс жди в этом же ходе: после выхода тебя никто не разбудит. - Отчёт — `/scratchpad/report-.md`, привяжи его к карточке. - В конце обнови память роли точечно; грабля ≥ 2 раз — в код, гейт или карту, не в память. - Финальный отчёт — канал подставляет запускатель по движку: Claude — SendMessage на имя штаба **<имя из файла состояния штаба>**, остальные движки — секция в инбокс штаба через свой адаптер. ## Роль <тело карточки роли> ## Бриф <тело брифа> ``` Запуск через запускатель: ```fish run-teammate --role web --brief /scratchpad/brief-.md --card --model opus ``` Запуск вручную (fish внутри tmux; для Sonnet-механики — `CLAUDE_CODE_EFFORT_LEVEL=medium` в окружении процесса: флаг CLI `--effort` у нас его не перебивал, проверяли по транскриптам): ```fish 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 минут, потом перевесить): ```bash t=0; until grep -Eq '^EXIT=-?[0-9]+[[:space:]]*$' /tmp/tmux-job-x.log || [ $t -ge 560 ]; do sleep 20; t=$((t+20)); done ``` Карточка решения: ```json {"id":"site-og-v2","type":"approve","owner":"max", "question":"OG-карточки v2 готовы на превью: новый шрифт, EN-заголовки.\n\nда → выкатываю на сайт; нет → остаётся v1", "default":"да","cost":"30 мин web-воркера, обратимо","artifact":"~/Vibe/site/scratchpad/report-og-v2.md", "ball":{"holder":"max","ask":{"kind":"permit","yes":"выкатываю OG v2 и проверяю превью"}}, "executor":{"role":"web","model":"sonnet"}} ``` ## Вопросы для адаптации 1. Сколько у тебя параллельных проектов и где сходятся их файлы (домашняя папка, база заметок, монорепо)? Там живёт штаб. 2. Какие подписки и CLI: Claude (Max/Pro), Codex, Grok, Gemini, ключи API? От этого зависят ярусы моделей и то, какие роли на каком движке могут жить. 3. Что для тебя human-only? Составь список из пяти–семи действий, которые делаешь только сам. Всё остальное агенты делают по умолчанию. 4. Ты один или с людьми? С людьми — реестр решений и инбокс становятся общими, роли получают владельцев. 5. Есть ли локальное железо под локальные модели? Тогда часть фоновых задач уходит на ноль, но считай честно: 27B-модель с длинным контекстом занимает 30 ГБ, и на 64 ГБ она мешает всему остальному. Без железа фон живёт на Haiku за копейки. 6. Где живут заметки и решения сейчас? Штабу нужна база, которую читает человек и куда агенты ходят по правам своей роли и движка (Obsidian-vault подходит идеально): там же будут карточки ролей и их память. 7. Какой ритм: работаешь днём и хочешь, чтобы ночью что-то происходило? Тогда launchd/cron-джобы с теми же брифами и отчётами и очередь команды в тихие часы. 8. Какие правила твой агент уже нарушил дважды? Это первые кандидаты в гейты. ## Нюансы и грабли - **Headless-сессия завершается, как только перестаёт звать инструменты.** Воркер, закончивший ход фразой «жду завершения рендера», просто вышел. Ждать можно только циклом в оболочке с таймаутом — правило стоит в каркасе каждого брифа. - **Лог headless-воркера пуст до самого конца.** Ноль байт через две минуты — не смерть; смерть — это отсутствие процесса. Сторож смотрит и на лог, и на tmux. - **Отчёт в шаблонное имя сессии — отчёт в никуда.** Поэтому имя штаба подставляет запускатель из файла состояния, а не автор брифа. - **`pkill -f <скрипт>` убивает tmux-сервер**, если строка совпала с его аргументами. Перед любым pkill — pgrep глазами. - **Общий репозиторий и параллельные воркеры** — чужие файлы уезжают в коммит и в деплой. Сначала инбокс и `git status`, потом сборка; в одно дерево — по одному писателю. - **`--fresh` перезаписывает состояние роли.** Две инстанции одной роли — вторую поднимай без роли или восстанавливай id вручную. - **Ctrl+Z — не выход.** Штаб, остановленный Ctrl+Z, остаётся живым процессом и держит лок «одна HQ». Новый запуск честно принимает себя за дубль и не работает. Лечение — завершить замороженную копию вместе с её осиротевшим сторожем: когда старый процесс мёртв, а возобновляется та же сессия, лок возвращается штатно. - **Дубль штаба рождал сам CLI.** Выход при живом мониторе предлагал «увести работу в фон и выйти»: разговор форкался в фоновую копию, и монитор переезжал в неё. Девять дней почти каждое утро рядом с живым штабом работала его копия с тем же контекстом. Решение в три слоя: обёртка выключает фоновый режим для процесса штаба, хук старта берёт лок, печатает стоп второй копии и не даёт ей переписать состояние основной, хук промпта блокирует фоновую копию. Вторую интерактивную копию эти слои не запрещают, а предупреждают — работать она технически может. Автоматически ничего не убиваем: показать, а не пристрелить. - **Воркеры печатают секреты, не желая того.** `docker compose config` раскрывает переменные, отладочный `echo` показывает токен, и значение уезжает в транскрипт, логи и память. Гард до команды и детектор после — раздел «Гейты». - **launchd, TCC и уведомления macOS.** Фоновые джобы launchd упираются в две системы. Первая показывает «может работать в фоне» по имени запускаемого файла и повторяет это при каждом пересканировании папки агентов, а пересканирование запускает любое изменение в ней. Вторая, доступ к папкам, считает ответственным сам процесс джобы, а не то, что он запускает. Решение — все 36 наших джоб стартуют через симлинки на один маленький бинарь-лаунчер: он пересылает сигналы и отдаёт код ребёнка, а грант доступа к папке — один на всех. Пересобирать лаунчер нельзя: новая подпись — новый грант и новая пачка уведомлений. - **Итоги легко начать дублировать в мессенджер.** Бот под рукой, и слать туда сводки удобно, но второй канал без спроса превращается в шум: человек и так видит итоги в карточках. 12 октября 2026 правило записали в карточку штаба: канал итогов — карточка, бот — только по просьбе человека или в ответ на задачу оттуда. - **Модель в коде — спрятанное решение.** С конца сентября по начало октября модели в реестре менялись четыре раза: штаб переехал с Fable на Opus 5.5, снят Opus 5, Sonnet 5 заменён на 5.5, Sol переехал на новую версию. Там, где id жил в реестре, смена была одной строкой; там, где был зашит в скрипт или текст, — правкой по файлам, которую легко недоделать. Этот блюпринт сам был таким местом: его v1 назывался по модели штаба. - **Автообновление плагинов стирает локальные патчи.** Всё, что патчил в кэше плагина, — записать в память с путём к оригиналу и проверкой после апдейта. - **Цена зависит от длины входа.** У части моделей ставка растёт, когда вход длиннее порога, и пороги у вендоров и моделей разные; у подписок свои условия. Проверяй тариф конкретной модели на дату сборки. Вывод тот же: брифы короткие, resume только при реальной нужде, толстую историю не таскать. - **Второй агент подтверждает вывод первого — это ещё не факт.** Согласие — тоже утверждение: принимаем после той же сверки, на чём держится и что сделало бы его неправдой. - **Карточка без дефолта и «подтвердить» без цены** — работа переложена на человека; такие карточки быстро перестают читать. - **Своё и чужое.** Содержимое закрытых спейсов, чатов и папок клиентов не переносится в другие контуры ни пересказом, ни намёком; наружу идёт только своё. Один воркер для всех проектов — самый частый способ это нарушить. ## Масштабирование - **Один воркер → флот.** Как только джоб больше двух в день — запускатель, сторожа по одному на джобу, `job-*` убивать после сбора результата, `dev-*` не трогать. - **Роли.** Когда один и тот же жанр повторяется (сайт, продукт, контент, продовые инциденты), заводи роль карточкой с памятью: грабли перестают повторяться. - **Дашборд.** Реестр решений, нити, очередь команды, инбокс, журнал, здоровье сервисов — одна локальная страница; телефон — мост в мессенджере. - **Другие движки.** Сначала воркеры по брифу через тот же запускатель, потом роли с несколькими движками в `platforms`. Долгоживущую главную сессию Codex с курсором инбокса и «тычком» очереди мы построили 1 сентября и свернули 16-го: за две недели человек ни разу не написал в её канонический тред, зато открыл 22 прямые нити, а курсор отставал на шесть дней. Живое — прямые нити человека и append-only лента от штаба; доставлено = ответный след. - **Локальные модели.** Фоновые вызовы — память, классификация, сжимка — можно увести на локальный сервер, когда модель помещается в память рядом с работой; до тех пор их держит дешёвая облачная модель, а облако посильнее остаётся для суждения. - **Ночная смена.** Launchd/cron-джобы с теми же брифами: дайджесты, вотчеры, бэкапы, синк заметок, утренняя и вечерняя очередь команды; их результаты линкуются в дневную ноту тем же ходом. ## Выходные артефакты Что coding agent собирает вместе с тобой по этому Blueprint: - Карточка штаба с правилами и глобальный `CLAUDE.md` с механикой. - Карта первого репозитория. - Папка ролей в базе заметок: две-три карточки и пустая `Memory.md` у каждой. - `models.json` с алиасами моделей. - Запускатель, который пишет каркас протокола, и шаблон брифа-тела. - `pending-decisions.json` и скрипты карточек с мячом и видом запроса. - Инбокс-файл, один Monitor штаба на него и первый Stop-гейт — «развилка в чате». - Конституция v0.1 на пять статей, первая — список human-only; правится только твоим словом. - Первая handoff-нота, чтобы завтрашний штаб начал не с нуля.