# Задание 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` по каждой сданной части.