Владелец описал рабочую схему: flash 3.7 пишет как Кодер 1, gemini pro проверяет его как Кодер 2 и возвращает на доработку до одобрения, опус 4.6 включается ревьюером после одобрения Pro и при необходимости возвращает работу Кодеру 2. Две вложенные петли. Смысл экономический: опус не тратится на то, что отсеет Pro, а Pro не тратится на то, что flash исправит сам. Имена моделей взяты из кэша обнаружения на аккаунтах владельца, а не из головы. Три места, где легко ошибиться, вынесены в задание отдельно: «гемини про» — это gemini-3.1-pro-high, версии 3.7 у Pro нет вовсе; «опус 4.6» называется claude-opus-4-6-thinking; у flash идентификаторы приходят с суффиксом усилия, но базовое имя gemini-3.7-flash валидно — ревьюер однажды уже утверждал обратное и был неправ. Отдельным пунктом — обязательные пределы итераций. Две вложенные петли без ограничителя жгут квоту молча, и это самый дорогой дефект в задании. Приёмка требует журнала живого прогона, где петля действительно сработала: конвейер, прошедший с первого раза, ничего не доказывает. Зависит от A35: без него хаб в вызовах Hermes не участвует и конвейер будет собран, но не заработает. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 KiB
Задание A36: рабочий конвейер Antigravity — оркестратор, два кодера, ревьюер
Дата поступления
2026-08-30
База
Ветка ревьюера review/a28-a31-fixes (ab2ee12).
git fetch origin --prune
git checkout -b antigravity/a36-pipeline origin/review/a28-a31-fixes
В main напрямую не пушить.
Порядок исполнения
Два прохода: Flash реализует, Pro проводит аудит. Пункт P0-5 написан для аудитора.
Зависит от A35. Без него хаб в вызовах Hermes не участвует, и конвейер будет собран, но не заработает. Собирать можно параллельно, принимать — только после A35.
Границы: A34 — веб-клиент и адаптеры, A35 — определение роли, здесь — конвейер и привязка моделей. Не пересекаться.
Задача
Владелец описал конвейер дословно:
«чтобы работал как оркестратор. флэш 3.7 кодер 1, гемини про кодер 2, проверяет работу кодера 1 и если надо, отправляет ему на доработку. и так, пока не сделают. ревьювер опус 4.6, проверяет, как гемини про одобрит работу. если надо, отправляет гемини про на переделку.»
То есть две петли обратной связи, вложенные одна в другую.
Модели — проверены, не выдумывать
Список снят ревьюером из кэша обнаружения на аккаунтах владельца. Обнаружено 14 моделей, из них нужны три:
| Роль владельца | Роль в реестре | Модель | Комментарий |
|---|---|---|---|
| Кодер 1 | developer-1 |
gemini-3.7-flash |
быстрый первый проход |
| Кодер 2 | developer-2 |
gemini-3.1-pro-high |
проверяет Кодера 1 |
| Ревьюер | code-reviewer |
claude-opus-4-6-thinking |
финальная проверка |
| Оркестратор | manager |
на усмотрение владельца | ведёт конвейер |
Три вещи, на которых легко ошибиться:
- «Гемини про» — это 3.1, а не 3.7. В обнаруженном списке есть
gemini-3.1-pro-highиgemini-3.1-pro-low; версии 3.7 у Pro нет вовсе. Подставлятьgemini-3.7-proнельзя, такой модели у провайдера нет. - «Опус 4.6» называется
claude-opus-4-6-thinking. Другого опуса в списке нет. - У flash идентификаторы приходят с суффиксом усилия —
gemini-3.7-flash-high,-medium,-low. Базовое имяgemini-3.7-flashпри этом валидно: уровень усилия — отдельный параметр, и A23 требует принимать базовое имя. Ревьюер однажды четырежды написал, чтоgemini-3.7-flash«не существует», и был неправ — см.agents/inbox/2026-08-24-CORRECTION-gemini-model-names.md. Не повторять.
Какой уровень усилия ставить Кодеру 1 — решает владелец; предложить в отчёте, молча не выбирать.
P0-1. Граф конвейера
Собрать в редакторе workflow из A30:
Оркестратор ──────────────► Кодер 1
│ SUCCESS
▼
Кодер 1 ◄──REVIEW_FAILED── Кодер 2
│ REVIEW_PASSED
▼
Кодер 2 ◄──REVIEW_FAILED── Ревьюер
│ REVIEW_PASSED
▼
Оркестратор (приёмка)
Смысл петель:
- Внутренняя. Кодер 2 проверяет работу Кодера 1. Не устраивает — возвращает на доработку, и так пока не одобрит.
- Внешняя. Ревьюер включается только после одобрения Кодера 2. Не устраивает — возвращает Кодеру 2, а не Кодеру 1.
Этот граф уже нарисован на утверждённом макете 1.1.png, включая подписи рёбер и красные пунктирные возвраты. Расхождение с макетом — дефект.
P0-2. Пределы итераций — обязательны
Две вложенные петли без ограничителя означают бесконечный прогон и сожжённую квоту.
- Предел на каждую петлю отдельно, настраиваемый. Значения по умолчанию предложить и обосновать; в код не зашивать.
- Достижение предела — явное событие в журнале и видимый результат, а не тихая остановка. На макете счётчик показан как «Итерация: 2 / 5».
- Общий предел прогона — на случай, если петли начнут чередоваться.
- Владелец должен видеть, на какой итерации идёт работа, в LIVE.
Механика защиты от бесконечного выполнения заложена в A30 (раздел 24 ТЗ). Второй реализации не заводить.
P0-3. Привязка моделей и аккаунтов
- Модель роли задаётся из интерфейса, действие
set_modelуже есть. - У каждой роли — свой аккаунт Antigravity, чтобы работы шли параллельно. У владельца их десять.
- Параллельность теперь настоящая. Глобальный мьютекс снят ревьюером в
7e83c38: было три параллельных вызова за 3.01 с, стало за 1.00 с. До этого из десяти аккаунтов одновременно работал один. Возвращать мьютекс нельзя, есть тест. - Одна и та же модель на разных ролях допустима, но разные аккаунты предпочтительнее: иначе квота одного сгорит на весь конвейер.
P0-4. Проверка живым прогоном
Отчёт без этого не принимается.
- Запустить конвейер на настоящей задаче и показать журнал: какая роль, какой аккаунт, какая модель, сколько итераций.
- Показать сработавшую петлю. Нужен прогон, где Кодер 2 вернул работу Кодеру 1 хотя бы раз, и это видно в событиях. Конвейер, где всё прошло с первого раза, ничего не доказывает.
- Показать срабатывание предела итераций: искусственно довести до него и убедиться, что прогон остановлен с внятным событием.
- Показать, что смена модели у роли меняет то, чем эта роль отвечает.
P0-5. Аудит вторым проходом
- Имена моделей. Сверить с обнаруженным списком:
gemini-3.1-pro-high,claude-opus-4-6-thinking,gemini-3.7-flash. Ни одного имени, которого провайдер не давал. - Петли без ограничителя — искать целенаправленно. Это самый дорогой дефект в задании: он жжёт квоту молча.
- Мьютекс не вернулся — тест должен проходить.
- Запустить, а не только протестировать. Прогон с реальной петлёй обязателен.
- Побочные изменения объяснить.
- Пропущенный пункт назвать пропущенным.
Ограничения
- Зона: workflow, конфигурация ролей и моделей, соответствующие тесты. Веб-мастер и адаптеры — A34, определение роли — A35.
- Правило честности: количество итераций, время, расход — только измеренные.
- Конфигурацию владельца литералами не править; конвейер собирается через существующие действия.
- Тег
v0.1.1не создавать.
Критерии приёмки
- Ветка в
originотreview/a28-a31-fixes,git statusчист. - Граф собран и совпадает с макетом
1.1.pngпо составу узлов, рёбер и условий. - Модели привязаны: Кодер 1 —
gemini-3.7-flash, Кодер 2 —gemini-3.1-pro-high, Ревьюер —claude-opus-4-6-thinking; имена совпадают с обнаруженным списком. - У ролей разные аккаунты; вызовы идут параллельно.
- Пределы итераций настраиваются, срабатывают, дают событие; значения не зашиты.
- Приложен журнал живого прогона, где петля сработала — Кодер 2 вернул работу Кодеру 1.
- Приложен прогон с достижением предела итераций.
- Смена модели у роли меняет поведение; проверено.
ruff check .чисто; релизный гейт не ухудшен.- Скриншоты: граф в EDIT, граф в LIVE во время прогона, счётчик итераций.
- Отчёт:
START_HEAD,FINAL_HEAD,origin/main,git status,X passed / Y skipped / Z failed. На ветке ревьюера сейчас 475 passed, 2 skipped.
Главное
Владелец хочет конвейер, где быстрая модель пишет, сильная проверяет и возвращает на доработку, а самая дорогая включается последней и только по делу. Смысл в экономии: опус не тратится на то, что отсеет Pro, а Pro не тратится на то, что исправит flash сам. Ради этого нужны обе петли и обязательно — ограничители.
Порядок сдачи
Передать точный FINAL_COMMIT_SHA.