diff --git a/Agent/Agent.md b/Agent/Agent.md
index 2dd6bb9..ca5fe56 100644
--- a/Agent/Agent.md
+++ b/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` и подготовить проект так, чтобы его можно было проверить по описанным требованиям.