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