docs: add workflow, architecture, DI and async rules to agent guidelines

- Add task status management section (Ready → In Progress → Done/Blocked)
- Add architectural rules for C# classes and MonoBehaviour usage
- Add dependency injection rules for Unity components and services
- Add async cancellation and cleanup rules with UniTask and CancellationToken
- Add UI subscription management rules with CompositeDisposable

Обновлены правила работы агента в Agent.md:
- Добавлена секция управления статусами задач (Ready → In Progress → Done/Blocked)
- Добавлены архитектурные правила для C# классов и MonoBehaviour
- Добавлены правила внедрения зависимостей для Unity компонентов и сервисов
- Добавлены правила async отмены и очистки с UniTask и CancellationToken
- Добавлены правила управления подписками UI с CompositeDisposable

Agent/Agent.md

@@ -46,6 +46,15 @@ Agent/Task/TASK_TEMPLATE.md
 6. Не добавлять лишние архитектурные слои, если они не нужны для выполнения задачи.
 7. Приоритет: минимальная корректная реализация, чистый жизненный цикл, понятный код.
 
+## Работа со статусами задач
+
+- Перед реализацией брать только задачи со статусом `Ready`.
+- При начале реализации переводить задачу в статус `In Progress`.
+- После выполнения, проверки и фиксации результата переводить задачу в статус `Done`.
+- Если задача заблокирована, переводить ее в статус `Blocked` и описывать причину в разделе `Заметки`.
+- Не начинать следующую задачу, если текущая задача в статусе `In Progress` не завершена и не заблокирована.
+- Если для выполнения текущей задачи появилась новая работа, создать новую задачу по шаблону, а не смешивать разные цели в одном файле.
+
 ## Правила заведения задач
 
 - Новые задачи создавать только в `Agent/Task/`.
@@ -70,6 +79,50 @@ Agent/Task/TASK_TEMPLATE.md
 - Все 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` и подготовить проект так, чтобы его можно было проверить по описанным требованиям.