hermes-hub/agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md

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