39ccce184c
Владелец описал рабочую схему: 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>
144 lines
12 KiB
Markdown
144 lines
12 KiB
Markdown
# Задание 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` | на усмотрение владельца | ведёт конвейер |
|
||
|
||
Три вещи, на которых легко ошибиться:
|
||
|
||
1. **«Гемини про» — это 3.1, а не 3.7.** В обнаруженном списке есть `gemini-3.1-pro-high` и `gemini-3.1-pro-low`; версии 3.7 у Pro нет вовсе. Подставлять `gemini-3.7-pro` нельзя, такой модели у провайдера нет.
|
||
2. **«Опус 4.6» называется `claude-opus-4-6-thinking`.** Другого опуса в списке нет.
|
||
3. **У 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. Пределы итераций — обязательны
|
||
|
||
Две вложенные петли без ограничителя означают бесконечный прогон и сожжённую квоту.
|
||
|
||
1. **Предел на каждую петлю отдельно**, настраиваемый. Значения по умолчанию предложить и обосновать; в код не зашивать.
|
||
2. **Достижение предела — явное событие** в журнале и видимый результат, а не тихая остановка. На макете счётчик показан как «Итерация: 2 / 5».
|
||
3. **Общий предел прогона** — на случай, если петли начнут чередоваться.
|
||
4. Владелец должен видеть, на какой итерации идёт работа, **в LIVE**.
|
||
|
||
Механика защиты от бесконечного выполнения заложена в A30 (раздел 24 ТЗ). Второй реализации не заводить.
|
||
|
||
## P0-3. Привязка моделей и аккаунтов
|
||
|
||
1. Модель роли задаётся из интерфейса, действие `set_model` уже есть.
|
||
2. У каждой роли — свой аккаунт Antigravity, чтобы работы шли параллельно. У владельца их десять.
|
||
3. **Параллельность теперь настоящая.** Глобальный мьютекс снят ревьюером в `7e83c38`: было три параллельных вызова за 3.01 с, стало за 1.00 с. До этого из десяти аккаунтов одновременно работал один. Возвращать мьютекс нельзя, есть тест.
|
||
4. Одна и та же модель на разных ролях допустима, но **разные аккаунты предпочтительнее**: иначе квота одного сгорит на весь конвейер.
|
||
|
||
## P0-4. Проверка живым прогоном
|
||
|
||
Отчёт без этого не принимается.
|
||
|
||
1. Запустить конвейер на настоящей задаче и показать журнал: какая роль, какой аккаунт, какая модель, сколько итераций.
|
||
2. **Показать сработавшую петлю.** Нужен прогон, где Кодер 2 вернул работу Кодеру 1 хотя бы раз, и это видно в событиях. Конвейер, где всё прошло с первого раза, ничего не доказывает.
|
||
3. Показать срабатывание предела итераций: искусственно довести до него и убедиться, что прогон остановлен с внятным событием.
|
||
4. Показать, что смена модели у роли меняет то, чем эта роль отвечает.
|
||
|
||
## P0-5. Аудит вторым проходом
|
||
|
||
1. **Имена моделей.** Сверить с обнаруженным списком: `gemini-3.1-pro-high`, `claude-opus-4-6-thinking`, `gemini-3.7-flash`. Ни одного имени, которого провайдер не давал.
|
||
2. **Петли без ограничителя** — искать целенаправленно. Это самый дорогой дефект в задании: он жжёт квоту молча.
|
||
3. **Мьютекс не вернулся** — тест должен проходить.
|
||
4. **Запустить, а не только протестировать.** Прогон с реальной петлёй обязателен.
|
||
5. **Побочные изменения** объяснить.
|
||
6. **Пропущенный пункт назвать пропущенным.**
|
||
|
||
---
|
||
|
||
## Ограничения
|
||
|
||
- Зона: workflow, конфигурация ролей и моделей, соответствующие тесты. Веб-мастер и адаптеры — A34, определение роли — A35.
|
||
- Правило честности: количество итераций, время, расход — только измеренные.
|
||
- Конфигурацию владельца литералами не править; конвейер собирается через существующие действия.
|
||
- Тег `v0.1.1` не создавать.
|
||
|
||
## Критерии приёмки
|
||
|
||
1. Ветка в `origin` от `review/a28-a31-fixes`, `git status` чист.
|
||
2. Граф собран и совпадает с макетом `1.1.png` по составу узлов, рёбер и условий.
|
||
3. Модели привязаны: Кодер 1 — `gemini-3.7-flash`, Кодер 2 — `gemini-3.1-pro-high`, Ревьюер — `claude-opus-4-6-thinking`; имена совпадают с обнаруженным списком.
|
||
4. У ролей разные аккаунты; вызовы идут параллельно.
|
||
5. Пределы итераций настраиваются, срабатывают, дают событие; значения не зашиты.
|
||
6. **Приложен журнал живого прогона, где петля сработала** — Кодер 2 вернул работу Кодеру 1.
|
||
7. Приложен прогон с достижением предела итераций.
|
||
8. Смена модели у роли меняет поведение; проверено.
|
||
9. `ruff check .` чисто; релизный гейт не ухудшен.
|
||
10. **Скриншоты:** граф в EDIT, граф в LIVE во время прогона, счётчик итераций.
|
||
11. Отчёт: `START_HEAD`, `FINAL_HEAD`, `origin/main`, `git status`, `X passed / Y skipped / Z failed`. На ветке ревьюера сейчас **475 passed, 2 skipped**.
|
||
|
||
## Главное
|
||
|
||
Владелец хочет конвейер, где быстрая модель пишет, сильная проверяет и возвращает на доработку, а самая дорогая включается последней и только по делу. Смысл в экономии: опус не тратится на то, что отсеет Pro, а Pro не тратится на то, что исправит flash сам. Ради этого нужны обе петли и обязательно — ограничители.
|
||
|
||
## Порядок сдачи
|
||
Передать точный `FINAL_COMMIT_SHA`.
|