docs(agents): задания A28, A29, A30 — новый фронтенд и субагенты
Владелец передал готовый дизайн: брендбук с тремя темами, макеты главного экрана, маршрутизации и остальных разделов, логотипы. Плюс список из двенадцати субагентов с расписанными обязанностями. Объём не помещается в одно задание, поэтому разделено на три с явными границами по файлам: 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>
This commit is contained in:
Hermes Team
parent
d5429da63d
commit
1a21c8b1a8
3 changed files with 487 additions and 0 deletions
161
agents/inbox/2026-08-25-A28-subagents-and-role-registry.md
Normal file
161
agents/inbox/2026-08-25-A28-subagents-and-role-registry.md
Normal file
|
|
@ -0,0 +1,161 @@
|
||||||
|
# Задание A28: субагенты и реестр ролей
|
||||||
|
|
||||||
|
## Дата поступления
|
||||||
|
2026-08-25
|
||||||
|
|
||||||
|
## База
|
||||||
|
Проверочный HEAD на момент выдачи: **`d5429da`**.
|
||||||
|
|
||||||
|
## Ветка
|
||||||
|
`antigravity/subagents-role-registry`
|
||||||
|
|
||||||
|
## Порядок исполнения
|
||||||
|
|
||||||
|
Два прохода: **Flash** реализует, **Pro** проводит аудит. Пункт **P0-5** написан для аудитора.
|
||||||
|
|
||||||
|
Это **первое** из трёх заданий по новому фронтенду (A28, A29, A30) и **основа для остальных**: главный экран рисует агентов, поэтому агенты должны появиться раньше экрана. A29 и A30 опираются на реестр ролей отсюда.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Порядок работы с git
|
||||||
|
|
||||||
|
```
|
||||||
|
cd <каталог репозитория>; git fetch origin --prune; git status
|
||||||
|
git checkout main; git pull --ff-only origin main
|
||||||
|
git checkout -b antigravity/subagents-role-registry
|
||||||
|
git commit -m "..." <- сначала коммит
|
||||||
|
git push -u origin antigravity/subagents-role-registry
|
||||||
|
```
|
||||||
|
|
||||||
|
В `main` напрямую не пушить. В конце — push, `git log --oneline -1`, `git status` чистый.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Задача
|
||||||
|
|
||||||
|
Сейчас в системе **шесть** ролей. Владелец хочет двенадцать — полноценную команду субагентов с внятно расписанными обязанностями. Список и формулировки даны им дословно и приведены ниже; **менять их смысл нельзя**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Что проверено исполнением — заново не выясняйте
|
||||||
|
|
||||||
|
**1. Новая роль добавляется через конфигурацию и доходит до снапшота.**
|
||||||
|
|
||||||
|
```
|
||||||
|
ролей в умолчаниях: 6 -> orchestrator, coder-primary, coder-secondary, reviewer, research, fast
|
||||||
|
после добавления роли tester в router_profiles.yaml: True
|
||||||
|
видна ли в снапшоте: True
|
||||||
|
```
|
||||||
|
|
||||||
|
Архитектуру ломать не нужно: `config.roles` уже произвольный словарь.
|
||||||
|
|
||||||
|
**2. Но подпись падает в сырой идентификатор.** У добавленной роли `role_name_ru` оказался `tester`, а не человеческое имя, потому что таблица подписей зашита в код:
|
||||||
|
|
||||||
|
```
|
||||||
|
unified_health.py:775 ROLE_NAMES = {...} семь записей
|
||||||
|
auto_assigner.py:28 HUMAN_ROLE_LABELS = {...} одиннадцать записей
|
||||||
|
```
|
||||||
|
|
||||||
|
**3. Список ролей зашит ещё в двух местах:**
|
||||||
|
|
||||||
|
```
|
||||||
|
auto_assigner.py:371 canonical_roles = ["orchestrator", "coder-primary", ...]
|
||||||
|
telemetry_service.py:402 roles = set(known_roles or ["orchestrator", ...])
|
||||||
|
```
|
||||||
|
|
||||||
|
Пока эти списки литеральные, новые роли будут выпадать из авто-распределения и из аналитики.
|
||||||
|
|
||||||
|
**4. Понятия «субагент» как сущности нет.** `universal_subagent` в `auto_assigner` — это подпись слота, а не отдельный агент. Файлов агентов (`agents/*.md`) в проекте нет вовсе.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## P0-1. Реестр ролей вместо литералов
|
||||||
|
|
||||||
|
Завести **один** источник истины для ролей: идентификатор, человеческое имя, описание обязанностей, порядок отображения.
|
||||||
|
|
||||||
|
Все четыре места выше должны читать оттуда. Литеральных списков ролей в коде остаться не должно — проверяется поиском.
|
||||||
|
|
||||||
|
Реестр обязан оставаться **расширяемым**: владелец добавляет роль в конфигурацию, и она появляется всюду — в маршрутизации, в обзоре, в аналитике, в авто-распределении — с человеческой подписью, а не с сырым идентификатором.
|
||||||
|
|
||||||
|
## P0-2. Двенадцать ролей и их обязанности
|
||||||
|
|
||||||
|
Формулировки владельца. Описание каждой роли обязано быть **видно в интерфейсе** — на карточке агента и в инспекторе, а не только в конфигурации.
|
||||||
|
|
||||||
|
| Идентификатор | Имя | Обязанности |
|
||||||
|
|---|---|---|
|
||||||
|
| `researcher` | Исследователь | Изучает данные, кодовую базу, документацию и внешние источники, чтобы собрать информацию для решения задачи. |
|
||||||
|
| `developer-1` | Разработчик 1 | Пишет код, реализует функционал, исправляет ошибки. |
|
||||||
|
| `developer-2` | Разработчик 2 | Проверяет код Разработчика 1 и выдаёт ему задание на исправление. |
|
||||||
|
| `code-reviewer` | Код-ревьювер | Анализирует код на ошибки, проблемы безопасности и соответствие стандартам. Работает **после** Разработчика 2. |
|
||||||
|
| `tester` | Тестировщик | Создаёт тесты, проверяет корректность работы кода, находит дефекты. |
|
||||||
|
| `tech-writer` | Технический писатель | Создаёт документацию, инструкции, README. |
|
||||||
|
| `analyst` | Аналитик | Проводит глубокий анализ данных, выявляет тренды, строит прогнозы. |
|
||||||
|
| `guardian` | Надзиратель (агент безопасности) | Проверяет входящие инструкции на промпт-инъекции, анализирует планы и вызовы инструментов, блокирует обход системных правил, не допускает утечки секретов, следит за границами песочницы. |
|
||||||
|
| `cost-controller` | Агент контроля затрат | Оценивает планируемый расход токенов, сравнивает с остатком бюджета, предлагает упрощения, сверяет факт с прогнозом, останавливает цепочку при исчерпании лимита. |
|
||||||
|
| `manager` | Менеджер (планировщик) | Определяет стратегию, распределяет ресурсы, контролирует ход выполнения. |
|
||||||
|
| `integration-expert` | Специалист по интеграции | Работает с API и внешними сервисами, отправляет вебхуки. |
|
||||||
|
| `security-expert` | Юрист / специалист по безопасности | Проверяет код и данные на уязвимости. |
|
||||||
|
|
||||||
|
Порядок в таблице — порядок отображения.
|
||||||
|
|
||||||
|
**Существующие шесть ролей не удалять и не переименовывать молча.** У владельца в конфигурации на трёх машинах живут `orchestrator`, `coder-primary`, `coder-secondary`, `reviewer`, `research`, `fast`, и на них ссылаются цепочки. Предложите соответствие старых новым (например `research` → `researcher`, `coder-primary` → `developer-1`) и **проведите миграцию**, сохранив цепочки. Соответствие описать в отчёте; спорные случаи вынести владельцу, а не решать молча.
|
||||||
|
|
||||||
|
## P0-3. Надзиратель и контроль затрат — особый случай
|
||||||
|
|
||||||
|
Эти двое отличаются от остальных: они не выполняют задачу пользователя, а **проверяют** работу других.
|
||||||
|
|
||||||
|
Задание **не требует** реализовывать их поведение — это отдельная работа. Требуется:
|
||||||
|
|
||||||
|
1. Завести их как роли наравне с прочими, с полным описанием обязанностей в интерфейсе.
|
||||||
|
2. **Честно показать, что исполнение ещё не реализовано.** Не рисовать зелёный статус «Работает» у агента, который ничего не делает. Состояние «Роль объявлена, исполнение не реализовано» — допустимо и честно; выдуманная активность — нет.
|
||||||
|
|
||||||
|
Правило проекта без исключений: ни одного статуса, числа или метрики без основания.
|
||||||
|
|
||||||
|
## P0-4. Двенадцать ролей и квоты
|
||||||
|
|
||||||
|
Двенадцать агентов на нескольких аккаунтах — это про распределение нагрузки, и здесь легко всё сломать.
|
||||||
|
|
||||||
|
- Один аккаунт по-прежнему может обслуживать несколько ролей (проверено в A26, движок это держит).
|
||||||
|
- Авто-распределение из A26 обязано работать и на двенадцати ролях: при одном провайдере он встаёт во все двенадцать, при нескольких — по назначению.
|
||||||
|
- Пороги квот из A26 не должны деградировать.
|
||||||
|
|
||||||
|
Прогоните авто-распределение на двенадцати ролях и приложите вывод.
|
||||||
|
|
||||||
|
## P0-5. Аудит вторым проходом
|
||||||
|
|
||||||
|
1. **Литеральные списки ролей.** Пройдите поиском по `orchestrator`, `coder-primary`, `reviewer` и убедитесь, что нигде не осталось зашитого перечня. Именно из-за таких списков добавленная роль показывалась как `tester`.
|
||||||
|
2. **Выдуманные статусы.** Особый риск в P0-3: у нереализованных ролей не должно быть активности, метрик и зелёных индикаторов.
|
||||||
|
3. **Миграция конфигурации владельца.** Проверьте на копии его `router_profiles.yaml`, что цепочки уцелели и маршрутизация работает. Конфигурацию литералами не править.
|
||||||
|
4. **Запустить изменённое**, а не только импортировать.
|
||||||
|
5. **Побочные изменения** объяснить.
|
||||||
|
6. **Пропущенный пункт назвать пропущенным.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Десктоп (`router/ui/**`) не трогать.
|
||||||
|
- Ваша зона: `auto_assigner.py`, `unified_health.py`, `telemetry_service.py`, `router_config.py`, конфигурации, соответствующие тесты и минимальные правки веб-клиента для показа описаний.
|
||||||
|
- Граф workflow и связи между агентами — **не здесь**, это A30. Не начинайте.
|
||||||
|
- Дизайн-система и темы — **не здесь**, это A29.
|
||||||
|
- Правило честности без исключений.
|
||||||
|
- Тег `v0.1.1` не создавать.
|
||||||
|
|
||||||
|
## Критерии приёмки
|
||||||
|
|
||||||
|
1. Ветка в `origin`, `git status` чист.
|
||||||
|
2. Двенадцать ролей заведены, у каждой человеческое имя и описание обязанностей; описание видно в интерфейсе.
|
||||||
|
3. Литеральных списков ролей в коде не осталось; проверено поиском, результат в отчёте.
|
||||||
|
4. Добавление роли в конфигурацию даёт человеческую подпись всюду; проверено на роли, которой нет в реестре по умолчанию.
|
||||||
|
5. Существующие шесть ролей мигрированы, цепочки владельца уцелели; проверено на копии его конфигурации.
|
||||||
|
6. Авто-распределение отработало на двенадцати ролях; вывод приложен.
|
||||||
|
7. У ролей без реализации исполнения нет выдуманной активности и метрик.
|
||||||
|
8. `ruff check .` чисто; релизный гейт не ухудшен.
|
||||||
|
9. Отчёт: `START_HEAD`, `FINAL_HEAD`, `origin/main`, `git status`, `X passed / Y skipped / Z failed`. На `main` сейчас **450 passed, 2 skipped**.
|
||||||
|
|
||||||
|
## Главное
|
||||||
|
|
||||||
|
Двенадцать субагентов с внятными обязанностями — основа нового главного экрана. Пока роли зашиты литералами, ни новый экран, ни маршрутизация из A29 нормально не заработают.
|
||||||
|
|
||||||
|
## Порядок сдачи
|
||||||
|
Передать точный `FINAL_COMMIT_SHA`. Сдано только после появления коммита в `origin`.
|
||||||
158
agents/inbox/2026-08-25-A29-design-system-and-routing.md
Normal file
158
agents/inbox/2026-08-25-A29-design-system-and-routing.md
Normal file
|
|
@ -0,0 +1,158 @@
|
||||||
|
# Задание A29: дизайн-система «Крона» и новый экран «Маршрутизация»
|
||||||
|
|
||||||
|
## Дата поступления
|
||||||
|
2026-08-25
|
||||||
|
|
||||||
|
## База
|
||||||
|
Проверочный HEAD на момент выдачи: **`d5429da`**.
|
||||||
|
|
||||||
|
## Ветка
|
||||||
|
`antigravity/design-system-routing`
|
||||||
|
|
||||||
|
## Порядок исполнения
|
||||||
|
|
||||||
|
Два прохода: **Flash** реализует, **Pro** проводит аудит. Пункт **P0-5** написан для аудитора.
|
||||||
|
|
||||||
|
Второе из трёх заданий по новому фронтенду. Идёт **после A28** (реестр ролей) и **параллельно A30** (главный экран) — границы по файлам ниже.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Порядок работы с git
|
||||||
|
|
||||||
|
```
|
||||||
|
cd <каталог репозитория>; git fetch origin --prune; git status
|
||||||
|
git checkout main; git pull --ff-only origin main
|
||||||
|
git checkout -b antigravity/design-system-routing
|
||||||
|
git commit -m "..." <- сначала коммит
|
||||||
|
git push -u origin antigravity/design-system-routing
|
||||||
|
```
|
||||||
|
|
||||||
|
В `main` напрямую не пушить.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Исходные материалы
|
||||||
|
|
||||||
|
Владелец передал готовый дизайн. Он лежит у него на рабочем столе, в репозиторий не копировался (там растровые макеты и логотипы):
|
||||||
|
|
||||||
|
```
|
||||||
|
Брендбук.txt дизайн-система: палитра, три темы, типографика
|
||||||
|
Брендбук Hermes Hub.png, Брендбук Hermes Hub 2.png
|
||||||
|
Hermes Hub.png эталонный логотип
|
||||||
|
3.txt полное ТЗ по вкладке «Маршрутизация»
|
||||||
|
3.1.png утверждённый макет «Маршрутизации» (светлая тема)
|
||||||
|
2.1.png … 7.1.png остальные экраны
|
||||||
|
лого агентов.png знаки агентов
|
||||||
|
claude.png, grok.jfif, antигравити.png, opencode.png,
|
||||||
|
llama.png, ollama.png, nvidia.png, чат гпт.png логотипы провайдеров
|
||||||
|
```
|
||||||
|
|
||||||
|
**Попросите файлы у владельца перед началом.** Работать по пересказу нельзя: макет — источник истины, и расхождение с ним будет считаться дефектом.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## P0-1. Дизайн-система: токены и три темы
|
||||||
|
|
||||||
|
Из `Брендбук.txt`. Базовая палитра задана явно:
|
||||||
|
|
||||||
|
| Token | Цвет | Назначение |
|
||||||
|
|---|---|---|
|
||||||
|
| `brand-primary` | `#101510` | глубокий фирменный зелёный |
|
||||||
|
| `brand-dark` | `#1A2A1F` | панели и поверхности |
|
||||||
|
| `brand-secondary` | `#2F4A36` | активные и вторичные поверхности |
|
||||||
|
| `brand-light` | `#F7F1E3` | фирменный кремовый |
|
||||||
|
| `brand-gold` | `#CDAA64` | основной золотой акцент |
|
||||||
|
|
||||||
|
Системные цвета: зелёный — успех и работа, янтарный — проверка и ожидание, красный — ошибка и возврат, синий — очередь, серо-бежевый — завершено и неактивно.
|
||||||
|
|
||||||
|
**Три темы: Dark, Medium, Light.** Ключевое из брендбука, что легко упустить:
|
||||||
|
|
||||||
|
- **Medium — не осветлённый Dark**, а отдельная тема: приглушённый тёмно-зелёный фон и **светлые кремовые карточки агентов** на зелёном холсте.
|
||||||
|
- **Light не использует чистый `#FFFFFF`**: база — тёплый кремовый около `#F7F1E3`.
|
||||||
|
- Золото **не должно заливать интерфейс целиком** — только бренд, акценты, активные элементы и связи.
|
||||||
|
|
||||||
|
Требования к реализации:
|
||||||
|
|
||||||
|
1. Все цвета — **переменными CSS**, ни одного literal-цвета в разметке и в JS. Тема переключается сменой набора переменных, а не подменой стилей.
|
||||||
|
2. Переключатель тем в «Настройках», выбор сохраняется.
|
||||||
|
3. Существующие семь разделов переводятся на токены целиком. Экран, оставшийся на старых цветах, — незавершённая работа.
|
||||||
|
|
||||||
|
Логотип: геометрию эталонного знака **не перерисовывать**. Для малых размеров допустима упрощённая версия на основе `H + корни`, производная от основного знака.
|
||||||
|
|
||||||
|
## P0-2. Экран «Маршрутизация» по макету `3.1.png` и ТЗ `3.txt`
|
||||||
|
|
||||||
|
Это самая ценная часть задания: владелец жаловался на текущую маршрутизацию с первого дня.
|
||||||
|
|
||||||
|
Назначение вкладки, дословно из ТЗ: она отвечает за **очерёдность аккаунтов внутри каждого агента**. Связи между агентами живут на главном экране и здесь не настраиваются.
|
||||||
|
|
||||||
|
Структура экрана:
|
||||||
|
|
||||||
|
- **слева и по центру** — маршруты всех агентов;
|
||||||
|
- **справа** — постоянная панель «Доступные аккаунты» со всеми подключёнными аккаунтами системы.
|
||||||
|
|
||||||
|
Обязательное поведение:
|
||||||
|
|
||||||
|
1. **Перетаскивание аккаунта** из правой панели прямо в маршрут нужного агента. Плюс кнопка «+» как альтернатива — на макете она есть.
|
||||||
|
2. **Перестановка внутри маршрута** мышью: порядок — это приоритет отказоустойчивости, а не косметика.
|
||||||
|
3. В строке маршрута видно: номер по порядку, логотип провайдера, имя и почта аккаунта, **выбор модели**, квота (использовано и предел, полоса и процент), время сброса квоты, статус, кнопка удаления из роли.
|
||||||
|
4. Заголовок роли: имя, пометка важности, описание обязанностей (берётся из реестра A28), число аккаунтов, кнопка «Добавить».
|
||||||
|
5. Кнопка **«Сбросить к рекомендуемому»** в шапке — это авто-распределение из A26, второй реализации не заводить.
|
||||||
|
6. Поиск и фильтр по провайдеру в правой панели.
|
||||||
|
|
||||||
|
Действия только существующие: `save_chain`, `reorder_chain`, `assign_role`, `set_model`. Появится новое — впишите в `docs/web-api/CONTRACT.md`.
|
||||||
|
|
||||||
|
## P0-3. Честность данных на этом экране
|
||||||
|
|
||||||
|
Экран целиком построен на числах, поэтому риск выдумки здесь наивысший.
|
||||||
|
|
||||||
|
- Квоты, проценты и время сброса берутся из `quota_collector`. **Ни одного значения, которого не дал провайдер.**
|
||||||
|
- Квота неизвестна — «Н/Д» и причина, а не ноль и не пустая полоса, которую можно принять за исчерпание.
|
||||||
|
- Логотип провайдера, для которого файла не дали, — нейтральная заглушка, а не чужой знак.
|
||||||
|
- На макете стоят демонстрационные почты и числа (`coder-backup@mail.com`, `812K / 1.5M`). Это **иллюстрация**, а не данные. Ни одно из них не должно попасть в код.
|
||||||
|
|
||||||
|
Последнее — не теория: в прошлых раундах в мастере подключения уже находили выдуманные коды устройства `GRK-7842` и `CDX-9104`, а тест **требовал** их наличия.
|
||||||
|
|
||||||
|
## P0-4. Что не входит
|
||||||
|
|
||||||
|
- Главный экран, граф workflow, файлы агентов, LIVE-мониторинг — это **A30**, туда не заходить.
|
||||||
|
- Реестр ролей и двенадцать агентов — это **A28**. Здесь роли только **читаются**.
|
||||||
|
- Нижняя панель экосистемы (`Planner`, `Journal`, `Finance`, …) на макетах — соседние продукты. В этом задании она **не реализуется**; если рисуете, то как неактивную заготовку, и это оговаривается в отчёте.
|
||||||
|
|
||||||
|
## P0-5. Аудит вторым проходом
|
||||||
|
|
||||||
|
1. **Literal-цвета.** Поиском убедиться, что в разметке и в JS не осталось `#RRGGBB` мимо токенов. Иначе третья тема будет вечно «почти готова».
|
||||||
|
2. **Демонстрационные данные из макета** в коде — искать отдельно и целенаправленно.
|
||||||
|
3. **Все три темы открыть и посмотреть**, а не только Dark. Medium — отдельная тема, не осветлённый Dark; проверить именно это.
|
||||||
|
4. **Перетаскивание при отпускании вне зоны** не должно терять блок.
|
||||||
|
5. **Запустить изменённое.**
|
||||||
|
6. **Побочные изменения** объяснить.
|
||||||
|
7. **Пропущенный пункт назвать пропущенным.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Десктоп (`router/ui/**`) не трогать.
|
||||||
|
- Ваша зона: `router/web/static/**`, ассеты. Серверная часть — только если действию не хватает данных, и это оговаривается.
|
||||||
|
- **A30 работает в тех же файлах.** Разделение: A29 — `style.css`, темы, экран маршрутизации; A30 — главный экран и граф. Согласуйте границы до начала, конфликты решайте через владельца, а не молча переписывая чужое.
|
||||||
|
- Правило честности без исключений.
|
||||||
|
- Тег `v0.1.1` не создавать.
|
||||||
|
|
||||||
|
## Критерии приёмки
|
||||||
|
|
||||||
|
1. Ветка в `origin`, `git status` чист.
|
||||||
|
2. Три темы работают, переключаются, выбор сохраняется; **скриншоты всех трёх**.
|
||||||
|
3. Literal-цветов вне токенов нет; проверено поиском.
|
||||||
|
4. Маршрутизация соответствует `3.1.png`: две области, правая панель аккаунтов, перетаскивание, выбор модели, квоты, время сброса, удаление из роли.
|
||||||
|
5. Перетаскивание из панели в роль и перестановка внутри роли сохраняются и переживают перезапуск.
|
||||||
|
6. Ни одного значения из макета в коде; проверено отдельно.
|
||||||
|
7. Неизвестная квота показана как «Н/Д» с причиной, а не нулём.
|
||||||
|
8. `ruff check .` чисто; релизный гейт не ухудшен.
|
||||||
|
9. Отчёт: `START_HEAD`, `FINAL_HEAD`, `origin/main`, `git status`, `X passed / Y skipped / Z failed`.
|
||||||
|
|
||||||
|
## Главное
|
||||||
|
|
||||||
|
Владелец получает интерфейс, который выглядит как управляющая система его экосистемы, и экран маршрутизации, где аккаунты раскладываются по агентам мышью. Это то, чего он просил дольше всего.
|
||||||
|
|
||||||
|
## Порядок сдачи
|
||||||
|
Передать точный `FINAL_COMMIT_SHA`.
|
||||||
168
agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md
Normal file
168
agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md
Normal file
|
|
@ -0,0 +1,168 @@
|
||||||
|
# Задание 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` по каждой сданной части.
|
||||||
Loading…
Reference in a new issue