1a21c8b1a8
Владелец передал готовый дизайн: брендбук с тремя темами, макеты главного экрана, маршрутизации и остальных разделов, логотипы. Плюс список из двенадцати субагентов с расписанными обязанностями. Объём не помещается в одно задание, поэтому разделено на три с явными границами по файлам: A28 реестр ролей и двенадцать субагентов Antigravity, основа A29 дизайн-система и экран «Маршрутизация» Antigravity A30 главный экран: граф workflow, LIVE, файлы Codex Каждое опирается на состояние, снятое исполнением, чтобы агенты не переписывали работающее и не выясняли заново: - новая роль уже добавляется через конфигурацию и доходит до снапшота, но подпись падает в сырой идентификатор, потому что таблицы имён зашиты в четырёх местах; - workflow, связей между агентами и файлов агентов в проекте нет вовсе — это разработка с нуля, а не доработка; - источники данных для дашборда существуют и настоящие, параллельный заводить не нужно; - веб-слой без сборки, и это обосновано в контракте. В каждом задании отдельно оговорено, что демонстрационные значения с макетов (12 задач, 3.42 с, 94.2%, account-01) — иллюстрация и в код попасть не должны. Поверхность для выдуманных данных здесь самая большая за проект. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
168 lines
13 KiB
Markdown
168 lines
13 KiB
Markdown
# Задание A30 (Codex): главный экран «Обзор» — граф workflow, файлы агентов, LIVE
|
||
|
||
## Дата поступления
|
||
2026-08-25
|
||
|
||
## База
|
||
Проверочный HEAD на момент выдачи: **`d5429da`**.
|
||
|
||
## Ветка
|
||
`codex/workflow-canvas`
|
||
|
||
## Кому
|
||
|
||
Это задание для **Codex**. Оно самое тяжёлое из трёх: здесь не переделка существующего экрана, а **три новые подсистемы, которых в проекте нет вообще**. A28 и A29 идут у Antigravity параллельно.
|
||
|
||
---
|
||
|
||
## Порядок работы с git
|
||
|
||
```
|
||
cd <каталог репозитория>; git fetch origin --prune; git status
|
||
git checkout main; git pull --ff-only origin main
|
||
git checkout -b codex/workflow-canvas
|
||
git commit -m "..." <- сначала коммит
|
||
git push -u origin codex/workflow-canvas
|
||
```
|
||
|
||
В `main` напрямую не пушить.
|
||
|
||
---
|
||
|
||
## Исходные материалы
|
||
|
||
У владельца на рабочем столе. **Запросите их до начала работы** — макет является источником истины:
|
||
|
||
```
|
||
1.txt полное ТЗ, 34 раздела: модель агента, agent file, граф, LIVE, события
|
||
1.1.png утверждённый макет главного экрана (тёмная тема)
|
||
1.2.png, 1.3.png, 2.x, 4.1 … 7.1.png остальные состояния и экраны
|
||
Брендбук.txt дизайн-система, три темы
|
||
```
|
||
|
||
---
|
||
|
||
## Что проверено исполнением — исходите из этого
|
||
|
||
Ревьюер снял состояние на `d5429da`. **Заново не выясняйте.**
|
||
|
||
**1. Ни одной из трёх подсистем в проекте нет.** Поиск по `src/antigravity_provider/router/` даёт пусто:
|
||
|
||
```
|
||
workflow / edge / agent_graph -> нет ни одного файла
|
||
agent_file / AgentFile / agents/*.md -> нет
|
||
```
|
||
|
||
Это разработка с нуля, а не доработка.
|
||
|
||
**2. Роли уже произвольны.** Новая роль добавляется в `router_profiles.yaml` и доходит до снапшота — проверено. Реестр ролей с человеческими именами делает **A28**; здесь вы его потребитель, своего не заводите.
|
||
|
||
**3. Данные для дашборда уже есть и настоящие.** Снапшот отдаёт `profiles_by_provider`, `all_profiles`, `readiness`, `agents`, `providers`, `routing`, `quotas`, `metrics`. Телеметрия вызовов и латентности живёт в `telemetry_service`. Не выдумывайте параллельный источник — раздел 27 ТЗ («Источники данных Dashboard») перечисляет их явно.
|
||
|
||
**4. Веб-слой без сборки.** Обычный JavaScript и `fetch`, без npm, без фреймворка, без шага сборки. Это решение принято и обосновано в `docs/web-api/CONTRACT.md` разделом 1: проект ведут агенты на трёх машинах, и любой шаг сборки означает дрейф версий Node между ними. **React и подобное отклонены.** Граф рисуется своими средствами — SVG или canvas.
|
||
|
||
**5. Все действия идут через один слой.** `POST /api/action` с именем действия из `action_handler.py`. Новые действия — только вписав их в `docs/web-api/CONTRACT.md`.
|
||
|
||
---
|
||
|
||
## P0-1. Модель агента и файл агента
|
||
|
||
Разделы 5–8 и 13 ТЗ.
|
||
|
||
Агент — объект с идентификатором, ролью из реестра A28, назначением `Provider → Account → Model`, конфигурацией исполнения (температура, предел токенов, таймаут), набором инструментов и **файлом агента**.
|
||
|
||
Файл агента — markdown в `agents/`, на макете `agents/coder-2.md`. Его видно и правят прямо из инспектора.
|
||
|
||
Требования:
|
||
|
||
1. Создание, удаление и изменение назначения агента — из интерфейса.
|
||
2. Файл агента открывается и сохраняется; путь показывается настоящий и существующий. **Каждый путь в интерфейсе обязан существовать** — инструкция уже однажды вела на несуществующий `launcher/main.py`, и это стоило раунда.
|
||
3. Удаление агента, участвующего в маршруте или в графе, — с предупреждением о последствиях, а не молча.
|
||
|
||
## P0-2. Граф workflow
|
||
|
||
Разделы 14, 16–21, 24, 25 ТЗ. Это ядро задания.
|
||
|
||
Узлы — агенты, рёбра — переходы с условиями. На макете видны `SUCCESS`, `REVIEW_PASSED`, `REVIEW_FAILED`; сплошные линии — движение вперёд, пунктирные красные — возвраты.
|
||
|
||
Требуется:
|
||
|
||
1. Визуальное соединение агентов мышью, редактор ребра с условием перехода.
|
||
2. Последовательные **и циклические** маршруты: `Кодер 1 → Кодер 2 → Ревьюер`, возврат на доработку, повторная итерация.
|
||
3. **Защита от бесконечного выполнения** — раздел 24. Предел итераций виден пользователю (на макете «Итерация: 2 / 5»), достижение предела — явное событие, а не тихая остановка.
|
||
4. Режимы **LIVE** и **EDIT** — раздел 15. В LIVE граф отражает исполнение, в EDIT правится структура. Смешивать нельзя.
|
||
5. Мини-карта, масштаб, легенда состояний — всё это на макете есть.
|
||
|
||
Отменённое перетаскивание возвращает узел на место, а не теряет его.
|
||
|
||
## P0-3. LIVE-мониторинг и события
|
||
|
||
Разделы 22, 23, 26, 29–31 ТЗ.
|
||
|
||
Состояния агента: ожидает, работает, проверяет, ошибка, завершено. На макете подписаны цветами из брендбука.
|
||
|
||
Требуется: текущая задача агента, номер итерации, время выполнения, последние события с отметкой времени, журнал выполнения workflow, настоящие ошибки провайдеров с их текстом.
|
||
|
||
## P0-4. Правило отсутствия данных — раздел 28 ТЗ
|
||
|
||
Владелец вынес это в отдельный раздел, и не случайно. Правило проекта, оплаченное несколькими раундами:
|
||
|
||
**Ни одного числа, статуса, имени модели или метрики без измерения.** Нет данных — «Н/Д» **с причиной**. Идёт загрузка — так и сказать; загрузка и отсутствие данных различаются.
|
||
|
||
На макете `1.1.png` стоят демонстрационные значения: `12` активных задач, `3.42 с`, `1.42M` токенов, `94.2%`, `42` выполненных, почты `account-01…04`. Это **иллюстрация**. Ни одно из них не должно попасть в код.
|
||
|
||
История: в прошлых раундах уже находили выдуманные проценты квот и выдуманные коды устройства `GRK-7842` и `CDX-9104`, причём тест **требовал** их наличия, то есть защищал выдумку от исправления. Здесь поверхность для такой ошибки самая большая за всё время проекта.
|
||
|
||
## P0-5. Порядок сдачи по частям
|
||
|
||
Задание крупное, и сдавать его одним куском не нужно. Разумное деление, каждая часть работоспособна сама по себе:
|
||
|
||
1. Модель агента, файл агента, инспектор — **без** графа.
|
||
2. Граф в режиме EDIT: узлы, рёбра, условия, сохранение.
|
||
3. Режим LIVE: состояния, события, итерации, журнал.
|
||
4. Дашборд: показатели и панели из настоящих источников.
|
||
|
||
После каждой части — рабочее приложение. Незаконченная часть обозначается в интерфейсе честно, а не рисуется заглушкой.
|
||
|
||
## P0-6. Самопроверка перед сдачей
|
||
|
||
1. **Запустить и посмотреть.** Импорт и зелёные тесты ничего не доказывают: в этом проекте уже был случай, когда модуль импортировался, тесты проходили, а приложение не запускалось вовсе.
|
||
2. **Проверить все три темы**, если A29 к тому моменту влит.
|
||
3. **Проверить каждый путь и команду**, показанные в интерфейсе.
|
||
4. **Отдельно пройти по новому коду** и убедиться, что ни одно значение с макета не стало литералом.
|
||
5. **Пропущенный пункт назвать пропущенным.** Это принимается; необъявленный пропуск — нет.
|
||
|
||
---
|
||
|
||
## Ограничения
|
||
|
||
- Десктоп (`router/ui/**`) не трогать: он выводится из обращения.
|
||
- **Без сборки, без npm, без фреймворка.** Решение обосновано в контракте.
|
||
- Действия только через `action_handler` и `POST /api/action`; новые — с правкой контракта.
|
||
- **A29 работает в тех же файлах.** Разделение: A29 — `style.css`, темы, экран маршрутизации; A30 — главный экран и граф. Границы согласовать до начала.
|
||
- Экран «Маршрутизация» — не ваш, это A29.
|
||
- Реестр ролей — не ваш, это A28.
|
||
- Нижняя панель экосистемы на макете — соседние продукты, здесь не реализуется.
|
||
- Правило честности без исключений.
|
||
- Тег `v0.1.1` не создавать.
|
||
|
||
## Критерии приёмки
|
||
|
||
1. Ветка в `origin`, `git status` чист.
|
||
2. Агент создаётся, удаляется, меняет назначение `Provider → Account → Model` из интерфейса; изменения переживают перезапуск.
|
||
3. Файл агента открывается и сохраняется; путь настоящий и существует.
|
||
4. Граф строится мышью, условия переходов задаются, циклы поддержаны, предел итераций виден и срабатывает.
|
||
5. Режимы LIVE и EDIT разделены.
|
||
6. Показатели дашборда взяты из настоящих источников; для каждого в отчёте указано, откуда именно.
|
||
7. Ни одного значения с макета в коде; проверено отдельно и описано.
|
||
8. Отсутствие данных показано как «Н/Д» с причиной; загрузка отличается от отсутствия.
|
||
9. `ruff check .` чисто; релизный гейт не ухудшен.
|
||
10. **Скриншоты:** главный экран в LIVE, в EDIT, инспектор агента, редактор ребра, файл агента.
|
||
11. Отчёт: `START_HEAD`, `FINAL_HEAD`, `origin/main`, `git status`, `X passed / Y skipped / Z failed`. На `main` сейчас **450 passed, 2 skipped**.
|
||
|
||
## Главное
|
||
|
||
Владелец должен с одного экрана видеть агентов, собирать из них workflow мышью, запускать и наблюдать исполнение вживую. Всё остальное в задании обслуживает это.
|
||
|
||
## Порядок сдачи
|
||
Передать точный `FINAL_COMMIT_SHA` по каждой сданной части.
|