QuizPlease/Agent/Agent.md

Правила для агента

Главный источник задачи

Перед началом любой работы по проекту агент обязан прочитать файл:

Agent/TASK.md

Именно этот файл считается основным описанием задачи, требований и ограничений.

Папка с задачами

Детальный план работ хранится в папке:

Agent/Task/

Задачи должны называться строго по формату:

TASK-0001.md
TASK-0002.md
TASK-0003.md

Новые задачи создаются только со следующим свободным номером. Нельзя пропускать номера без причины и нельзя переиспользовать номер удаленной или завершенной задачи.

Правила шаблона задач описаны в файле:

Agent/Task/TASK_TEMPLATE.md

Каждая новая задача обязана соблюдать этот шаблон.

Порядок работы

1. Сначала прочитать Agent/TASK.md полностью.
2. Прочитать Agent/Task/TASK_TEMPLATE.md.
3. Прочитать актуальные задачи Agent/Task/TASK-*.md.
4. После чтения сверять все решения с требованиями из задачи и конкретных task-файлов.
5. Не реализовывать вариант B или любую функциональность, которой нет в Agent/TASK.md или Agent/Task/TASK-*.md.
6. Не добавлять лишние архитектурные слои, если они не нужны для выполнения задачи.
7. Приоритет: минимальная корректная реализация, чистый жизненный цикл, понятный код.

Работа со статусами задач

• Перед реализацией брать только задачи со статусом Ready.
• При начале реализации переводить задачу в статус In Progress.
• После выполнения, проверки и фиксации результата переводить задачу в статус Done.
• Если задача заблокирована, переводить ее в статус Blocked и описывать причину в разделе Заметки.
• Не начинать следующую задачу, если текущая задача в статусе In Progress не завершена и не заблокирована.
• Если для выполнения текущей задачи появилась новая работа, создать новую задачу по шаблону, а не смешивать разные цели в одном файле.

Правила заведения задач

• Новые задачи создавать только в Agent/Task/.
• Имя файла должно быть TASK-XXXX.md, где XXXX — номер из четырех цифр.
• Заголовок задачи должен начинаться с того же номера, что и имя файла.
• Структура задачи должна соответствовать Agent/Task/TASK_TEMPLATE.md.
• В задаче должны быть разделы Статус, Цель, Что сделать, Технические требования, Критерии готовности, Заметки.
• Статус задачи должен быть одним из значений: Planned, Ready, In Progress, Done, Blocked.
• Задача должна быть достаточно крупной, чтобы не дробить работу на слишком много файлов.
• Задача должна быть достаточно конкретной, чтобы по критериям готовности можно было проверить результат.
• Нельзя заводить задачи по варианту B.

Ограничения

• Использовать VContainer для DI.
• Использовать UniTask для async-операций.
• Использовать UniRx для реактивных значений и подписок.
• Не использовать FindObjectOfType.
• Не использовать Singleton.Instance.
• Не хранить состояние в static.
• Не использовать async void, кроме Unity-колбэков.
• Все async-операции выполнять через UniTask и CancellationToken.
• Все подписки должны корректно освобождаться.

Архитектурные правила

• Orchestration-логика должна жить в plain C# классах.
• MonoBehaviour использовать только как View-компоненты и Unity binding layer.
• State не должен сам переключать state machine изнутри своего EnterAsync(...).
• Переходами между state управляет внешний flow coordinator.
• Generic state machine должна отвечать только за порядок ExitAsync текущего state и EnterAsync нового state.
• ViewModel должна быть обычным C#-классом.
• ViewModel передавать во View явно через bind/setup-метод, а не через DI-поля MonoBehaviour.
• View не должна содержать бизнес-логику boot flow и не должна напрямую управлять state machine.

Правила DI

• Scene View регистрировать через RegisterComponent(...).
• Settings/config assets регистрировать через [SerializeField] и RegisterInstance(...).
• Сервисы, controller-объекты и state-объекты не регистрировать через RegisterInstance(...).
• Сервисы регистрировать как интерфейсы через builder.Register<Impl>(Lifetime.Singleton).As<IInterface>().
• Runtime-данные не прокидывать в MonoBehaviour через DI-поля.
• Не создавать зависимости вручную внутри MonoBehaviour, если они должны управляться контейнером.

Правила async и отмены

• Каждый await должен получать CancellationToken, пришедший сверху, если операция поддерживает отмену.
• UniTask.Delay, UniTask.Yield и похожие операции должны использовать CancellationToken.
• CancellationToken не должен быть декоративным: отмена должна реально останавливать ожидания и фоновые операции.
• OperationCanceledException при штатной остановке flow, сцены или scope не считать ошибкой.
• Если операция должна завершаться по нескольким причинам, использовать CancellationTokenSource.CreateLinkedTokenSource(...).
• Linked CancellationTokenSource обязательно освобождать через Dispose().
• Фоновые циклы запускать в InitializeAsync и останавливать через CancellationTokenSource.Cancel() в ReleaseAsync.

Правила UI и подписок

• Для UniRx-подписок использовать CompositeDisposable.
• Подписки создавать при Initialize() или после явного bind/setup ViewModel.
• Все подписки очищать в Release().
• Release() должен быть идемпотентным и безопасным при повторном вызове.
• Сначала останавливать входящие сигналы и подписки, затем очищать ссылки на ViewModel и runtime-данные.
• Для Button.onClick использовать симметричные AddListener(...) и RemoveListener(...).
• Снимать нужно тот же listener, который был добавлен.
• Не использовать RemoveAllListeners() как основной способ очистки.
• Не использовать анонимные listeners, если их потом нельзя симметрично снять.
• Не обновлять реактивный UI через Update().
• Повторный вход во View не должен создавать дублирующиеся подписки или callbacks.

Цель

Сделать только задачу Boot Flow из Agent/TASK.md и подготовить проект так, чтобы его можно было проверить по описанным требованиям.