From 1a21c8b1a809b5aa03945003ec825b6f8b1cbf10 Mon Sep 17 00:00:00 2001 From: Hermes Team Date: Tue, 25 Aug 2026 19:05:56 +0700 Subject: [PATCH] =?UTF-8?q?docs(agents):=20=D0=B7=D0=B0=D0=B4=D0=B0=D0=BD?= =?UTF-8?q?=D0=B8=D1=8F=20A28,=20A29,=20A30=20=E2=80=94=20=D0=BD=D0=BE?= =?UTF-8?q?=D0=B2=D1=8B=D0=B9=20=D1=84=D1=80=D0=BE=D0=BD=D1=82=D0=B5=D0=BD?= =?UTF-8?q?=D0=B4=20=D0=B8=20=D1=81=D1=83=D0=B1=D0=B0=D0=B3=D0=B5=D0=BD?= =?UTF-8?q?=D1=82=D1=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Владелец передал готовый дизайн: брендбук с тремя темами, макеты главного экрана, маршрутизации и остальных разделов, логотипы. Плюс список из двенадцати субагентов с расписанными обязанностями. Объём не помещается в одно задание, поэтому разделено на три с явными границами по файлам: A28 реестр ролей и двенадцать субагентов Antigravity, основа A29 дизайн-система и экран «Маршрутизация» Antigravity A30 главный экран: граф workflow, LIVE, файлы Codex Каждое опирается на состояние, снятое исполнением, чтобы агенты не переписывали работающее и не выясняли заново: - новая роль уже добавляется через конфигурацию и доходит до снапшота, но подпись падает в сырой идентификатор, потому что таблицы имён зашиты в четырёх местах; - workflow, связей между агентами и файлов агентов в проекте нет вовсе — это разработка с нуля, а не доработка; - источники данных для дашборда существуют и настоящие, параллельный заводить не нужно; - веб-слой без сборки, и это обосновано в контракте. В каждом задании отдельно оговорено, что демонстрационные значения с макетов (12 задач, 3.42 с, 94.2%, account-01) — иллюстрация и в код попасть не должны. Поверхность для выдуманных данных здесь самая большая за проект. Co-Authored-By: Claude Opus 5 --- ...6-08-25-A28-subagents-and-role-registry.md | 161 +++++++++++++++++ ...026-08-25-A29-design-system-and-routing.md | 158 ++++++++++++++++ .../2026-08-25-A30-workflow-canvas-CODEX.md | 168 ++++++++++++++++++ 3 files changed, 487 insertions(+) create mode 100644 agents/inbox/2026-08-25-A28-subagents-and-role-registry.md create mode 100644 agents/inbox/2026-08-25-A29-design-system-and-routing.md create mode 100644 agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md diff --git a/agents/inbox/2026-08-25-A28-subagents-and-role-registry.md b/agents/inbox/2026-08-25-A28-subagents-and-role-registry.md new file mode 100644 index 0000000..035254f --- /dev/null +++ b/agents/inbox/2026-08-25-A28-subagents-and-role-registry.md @@ -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`. diff --git a/agents/inbox/2026-08-25-A29-design-system-and-routing.md b/agents/inbox/2026-08-25-A29-design-system-and-routing.md new file mode 100644 index 0000000..57a1ef8 --- /dev/null +++ b/agents/inbox/2026-08-25-A29-design-system-and-routing.md @@ -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`. diff --git a/agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md b/agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md new file mode 100644 index 0000000..bd88d9c --- /dev/null +++ b/agents/inbox/2026-08-25-A30-workflow-canvas-CODEX.md @@ -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` по каждой сданной части.