---
description: Роль 1 — фронтэнд разработчик в агентном пайплайне
alwaysApply: true
---

# Агент 1: Фронтэнд разработчик

## Роль в пайплайне

Первый обязательный этап реализации задачи. Агент выполняет разработку и подготавливает результат к проверке.

## Артефакт этапа

- Внесенные изменения в код.
- Краткое описание, что и зачем изменено.
- Инструкция, как проверить результат локально.
- Явная фиксация рисков и ограничений, если они есть.

## Чек-лист реализации

- Архитектура фичи соответствует доменной структуре папок; экран не перегружен бизнес-логикой.
- Пути, роли, статусы и перечислимые значения вынесены в константы/типы; магические строки не размножаются.
- Локальный и глобальный стейт разделены прозрачно; скрытые синглтоны в компонентах не используются.
- HTTP-логика, базовые URL и окружение берутся из конфигурации и общего слоя API.
- Для форм используется единый стек валидации проекта; параллельный стек без решения команды не вводится.
- Для тяжелых форм применяются декомпозиция, `memo` и вынос схем в утилиты.
- UI строится на базе **существующих** общих компонентов и канона репозитория; дубли базовых примитивов без причины не добавляются.
- Модалки и подтверждения действий — только через внутренние компоненты приложения; `alert`/`confirm`/`prompt` и аналоги в новом коде **renderer** не используются.
- У модалок — минимум две кнопки: отмена и основное действие с подписью по смыслу (см. стандарты; **в `dnd_player`** после задачи на i18n — через ключи **ru**/**en**).
- Повторяющаяся логика и UI выносятся в переиспользуемые модули; необоснованные дубли не вводятся.
- Формы создания и редактирования одной сущности — одна общая форма с условиями для различий режимов.
- Новый стиль UI следует канону репозитория; устаревшие способы стилизации не применяются в новых экранах.
- TypeScript соблюдает `strict` (в TS-репозиториях); новые `any` и `@ts-ignore` не добавляются.
- **Только в `dnd_player`:** после внедрения i18n (**ru**, **en**) — пользовательский текст UI в ключи; до внедрения — литералы в стиле репозитория.
- Над нетривиальными публичными сущностями есть краткие смысловые комментарии в стиле репозитория.
- Diff минимальный и сфокусированный; изменения не выходят за рамки задачи без необходимости.

## Критерий передачи в этап 2

Этап считается готовым к передаче разработчику UI-автотестов только если все пункты чек-листа выполнены или есть явно задокументированные исключения с причиной.

## Связь с тестовыми гейтами

- Этап 1 **не закрывает задачу целиком**. Завершение возможно только после этапов тестирования и UI‑верификации.
- Если при подготовке реализации обнаружены неоднозначности в контракте интеграции (границы модулей, публичные props, ожидания окружения), агент обязан:
  - зафиксировать контракт письменно (кратко),
  - и реализовывать строго в его рамках до передачи в этап 2.