[Add] New Tasks (The tasks have not been verified)

docs/tasks/Index.md

@@ -40,9 +40,23 @@
 
 | ID | Status | Priority | Area | Owner | Execution Time | File | Summary |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| TASK-0001 | Done | Medium | docs | unassigned | 1d | `docs/tasks/items/TASK-0001-define-docs-structure-and-migration-plan.md` | Определена целевая структура документации, карта миграции и последовательность работ для переноса docs. |
-| TASK-0002 | Done | Highest | docs | unassigned | 1d6h | `docs/tasks/items/TASK-0002-execute-docs-structure-migration.md` | Выполнен перенос дерева docs в разделы current, runbooks, history, process и tasks, а также обновлены пути входа в документацию. |
-| TASK-0003 | InProgress | High | ci_cd | unassigned | 2d | `docs/tasks/items/TASK-0003-stabilize-ci-cd-and-validate-pipeline.md` | Требуется итеративно стабилизировать текущий CI/CD путь на GitHub Actions и довести его до подтвержденно рабочего состояния. |
-| TASK-0004 | BackLog | Medium | product | unassigned | 1d | `docs/tasks/items/TASK-0004-define-directories-feature-and-implementation-decision.md` | Нужно согласовать и зафиксировать модель фичи directories, чтобы реализация не пошла в неверном направлении. |
-| TASK-0005 | Review | Medium | product | unassigned | 2d | `docs/tasks/items/TASK-0005-implement-directories-and-folder-navigation.md` | Реализацию directories нельзя начинать, пока `TASK-0004` не зафиксирует согласованную модель папок и границы выполнения. |
-| TASK-0006 | ToDo | Low | docs | unassigned | 1d | `docs/tasks/items/TASK-0006-reposition-readme-as-project-brief.md` | Нужно переписать `README`, чтобы он начинался с идентичности проекта, стека и верхнеуровневого онбординга. |
+| TASK-0001 | ToDo | Highest | architecture | unassigned | 1d | docs/tasks/items/TASK-0001.md | Зафиксировать MVP-архитектуру диаблоида на FishNet: разделение player/world, authority, детерминизм и контракты между подсистемами. |
+| TASK-0002 | ToDo | Highest | networking | unassigned | 1d | docs/tasks/items/TASK-0002.md | Реализовать сетевой bootstrap FishNet, лобби, выбор мира и подготовку игрока к входу в сессию. |
+| TASK-0003 | ToDo | Highest | worldgen | unassigned | 1d6h | docs/tasks/items/TASK-0003.md | Построить детерминированную генерацию мира по seed с поддержкой биомов и стабильной структуры чанков. |
+| TASK-0004 | ToDo | High | persistence | unassigned | 1d | docs/tasks/items/TASK-0004.md | Спроектировать раздельные сохранения мира и персонажей по модели Terraria-style. |
+| TASK-0005 | ToDo | Highest | spawning | unassigned | 1d | docs/tasks/items/TASK-0005.md | Реализовать детерминированный спавн врагов по seed, биому и координатам чанка. |
+| TASK-0006 | ToDo | Highest | persistence | unassigned | 1d | docs/tasks/items/TASK-0006.md | Реализовать побитовую систему состояния врагов в чанке и сохранить ее в world save. |
+| TASK-0007 | ToDo | Highest | gameplay-core | unassigned | 1d | docs/tasks/items/TASK-0007.md | Построить базовую боевую систему, уровни персонажа и связь прогрессии с уровнем оружия. |
+| TASK-0008 | ToDo | Highest | inventory | unassigned | 1d | docs/tasks/items/TASK-0008.md | Реализовать сетевой инвентарь и экипировку с сохранением в player save. |
+| TASK-0009 | ToDo | Highest | equipment | unassigned | 1d | docs/tasks/items/TASK-0009.md | Ввести абстрактную систему оружия с общими параметрами, scaling и точками расширения. |
+| TASK-0010 | ToDo | Highest | abilities | unassigned | 1d | docs/tasks/items/TASK-0010.md | Реализовать абстрактную систему скиллов и книг, которые вставляются в оружие. |
+| TASK-0011 | ToDo | High | characters | unassigned | 1d | docs/tasks/items/TASK-0011.md | Сделать базовую модель классов персонажей для Воина, Мага и Лучника. |
+| TASK-0012 | ToDo | Highest | ai | unassigned | 1d6h | docs/tasks/items/TASK-0012.md | Построить систему врагов на NavMesh с применением общей системы навыков. |
+| TASK-0013 | ToDo | High | ui | unassigned | 1d | docs/tasks/items/TASK-0013.md | Реализовать меню лобби, выбор персонажа и выбор мира перед входом в игровую сессию. |
+| TASK-0014 | ToDo | High | classes | unassigned | 1d | docs/tasks/items/TASK-0014.md | Реализовать MVP-скилл Воина: простой удар мечом через общую систему оружия и навыков. |
+| TASK-0015 | ToDo | High | classes | unassigned | 1d | docs/tasks/items/TASK-0015.md | Реализовать MVP-скилл Мага: условный AOE-каст через общую систему оружия и навыков. |
+| TASK-0016 | ToDo | High | classes | unassigned | 1d | docs/tasks/items/TASK-0016.md | Реализовать MVP-скилл Лучника: выстрел через общую систему оружия и навыков. |
+| TASK-0017 | BackLog | Medium | networking | unassigned | 1d | docs/tasks/items/TASK-0017.md | Добавить reconnect/resume после дисконнекта с восстановлением позиции и session state. |
+| TASK-0018 | BackLog | Medium | persistence | unassigned | 1d | docs/tasks/items/TASK-0018.md | Добавить миграции формата сохранений между версиями для world save и player save. |
+| TASK-0019 | BackLog | High | worldgen | unassigned | 1d6h | docs/tasks/items/TASK-0019.md | Добавить детерминированное размещение dungeon prefab в grid мира с вырезанием мировых тайлов под ним. |
+| TASK-0020 | BackLog | High | security | unassigned | 1d | docs/tasks/items/TASK-0020.md | Добавить серверные ограничения и валидации против читов и некорректных клиентских команд. |

docs/tasks/items/TASK-0001.md

@@ -0,0 +1,114 @@
+---
+id: TASK-0001
+title: Зафиксировать MVP-архитектуру диаблоида на FishNet
+summary: Описать каноническую архитектуру MVP, включая разделение player/world, authority, сетевые границы, детерминизм и связи между подсистемами.
+priority: Highest
+area: architecture
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on: []
+canonical_docs:
+  - docs/tasks/Index.md
+  - docs/tasks/_template.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+  - Assets/Scripts/WorldGen/WorldAutotileProfile.cs
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0001 - Зафиксировать MVP-архитектуру диаблоида на FishNet
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Без общей архитектуры легко получить несовместимые решения между генерацией мира, сетевым кодом, сохранениями, персонажами, инвентарем и AI. Эта задача должна зафиксировать правила MVP до начала активной реализации.
+
+## Expected Outcome
+
+Появляется документ или набор canonical notes, где определены: модель мира и игрока, границы ответственности сервера и клиента, правила детерминизма по seed, формат идентификаторов чанков и сущностей, а также зависимости между будущими системами.
+
+## Current Context
+
+В проекте уже есть рабочий слой генерации мира в `Assets/Scripts/WorldGen/*`, но нет зафиксированной архитектуры под сетевую игру, классы персонажей, боевую систему и сохранения.
+
+## Source Of Truth
+
+- `docs/tasks/Index.md`
+- код в `Assets/Scripts/WorldGen/*`
+- явные решения человека по MVP после создания этой задачи
+
+## Read First
+
+- `docs/tasks/Index.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+- `Assets/Scripts/WorldGen/WorldAutotileProfile.cs`
+- `Assets/Scripts/Player/SimplePlayerInputMover.cs`
+
+## Scope In
+
+- зафиксировать high-level архитектуру MVP
+- описать authority model для FishNet
+- определить канонические идентификаторы игрока, мира, чанка, врага и предмета
+- определить границы между runtime world data, player save data и session state
+
+## Scope Out
+
+- полноценная реализация подсистем
+- контентная балансировка
+
+## Constraints
+
+- сохраняйте существующий worldgen как стартовую точку, если человек явно не меняет направление
+- предпочитайте минимальную архитектуру, достаточную для MVP
+- все последующие задачи должны опираться на решения из этой задачи
+
+## If You Find Drift
+
+- если текущий код worldgen конфликтует с новой сетевой моделью, фиксируйте конфликт отдельно
+- не ломайте существующий editor tooling без отдельного решения
+
+## Suggested Approach
+
+1. Описать целевой gameplay loop MVP и обязательные подсистемы.
+2. Зафиксировать границы server authority, client prediction и persistence.
+3. Связать решения с конкретными task-файлами и артефактами кода.
+
+## Acceptance Criteria
+
+- есть каноническое описание архитектуры MVP с понятными границами подсистем
+- определено, где живут данные мира, игрока, сессии и чанка
+- определено, какие части обязаны быть детерминированными по seed
+
+## Verification
+
+- вычитка документа на непротиворечивость с `Index.md`
+- проверка, что все downstream task-файлы опираются на решения из этой задачи
+
+## Risks / Open Questions
+
+- без раннего решения по authority возможно придется переписывать боевую систему и AI
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - архитектурную задачу вынесли в отдельный highest-priority task перед реализацией сетевых и боевых систем.
+
+## Handoff Notes
+
+После фиксации архитектуры обновить `canonical_docs` в downstream task-файлах, если появится новый канонический документ.

docs/tasks/items/TASK-0002.md

@@ -0,0 +1,110 @@
+---
+id: TASK-0002
+title: Реализовать сетевой bootstrap, лобби и выбор мира
+summary: Поднять базовую сетевую инфраструктуру FishNet для хоста и клиента, лобби, выбора мира и подготовки игрока к входу в сессию.
+priority: Highest
+area: networking
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0001
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scenes/SampleScene.unity
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0002 - Реализовать сетевой bootstrap, лобби и выбор мира
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Без минимального сетевого bootstrap нельзя проверить ни совместную генерацию мира, ни синхронизацию персонажей, ни join flow из меню.
+
+## Expected Outcome
+
+Игрок может запустить host/server, подключиться клиентом в лобби, выбрать мир и перейти в игровую сессию через FishNet по фиксированному сценарию подключения.
+
+## Current Context
+
+В проекте пока нет видимого сетевого кода FishNet. Есть только локальные worldgen и player prototype скрипты.
+
+## Source Of Truth
+
+- `docs/tasks/Index.md`
+- решения из `TASK-0001`
+- реальный runtime-код FishNet после внедрения
+
+## Read First
+
+- `docs/tasks/items/TASK-0001.md`
+- `Assets/Scenes/SampleScene.unity`
+- `Assets/Scripts/Player/SimplePlayerInputMover.cs`
+
+## Scope In
+
+- интеграция базового startup flow FishNet
+- host/client connect flow
+- переход через лобби к выбору мира
+- серверное создание player session после выбора мира
+
+## Scope Out
+
+- reconnect/resume после дисконнекта
+- матчмейкинг, dedicated fleet и внешний backend
+
+## Constraints
+
+- сервер должен быть источником истины для подключения к миру
+- flow должен быть совместим с моделью Terraria-style: любой персонаж может зайти в любой мир
+
+## If You Find Drift
+
+- если текущая сцена прототипа мешает лобби flow, зафиксируйте это и вынесите сценовую декомпозицию в подзадачи реализации
+
+## Suggested Approach
+
+1. Внедрить FishNet и описать базовый boot pipeline.
+2. Сделать простое лобби с переходом к выбору мира.
+3. Добавить создание сетевой player session и вход в выбранную world session.
+
+## Acceptance Criteria
+
+- host может поднять сессию и принять клиента
+- клиент может выбрать мир и корректно появиться в нем
+- сетевой flow не привязывает персонажа к одному сохранению мира
+
+## Verification
+
+- ручная проверка host/client connect flow
+- проверка, что выбранный мир доступен в runtime join pipeline
+
+## Risks / Open Questions
+
+- потребуется раннее решение, использовать ли single-scene или multi-scene world session flow
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - лобби и выбор мира зафиксированы как часть сетевого bootstrap, а не отдельный поздний UI task.
+
+## Handoff Notes
+
+Дальнейшие UI-задачи должны использовать этот network flow как канонический сценарий подключения.

docs/tasks/items/TASK-0003.md

@@ -0,0 +1,112 @@
+---
+id: TASK-0003
+title: Построить детерминированную генерацию мира с биомами
+summary: Развить существующий worldgen до детерминированной генерации мира по seed с поддержкой биомов и стабильной структуры чанков.
+priority: Highest
+area: worldgen
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d6h
+depends_on:
+  - TASK-0001
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+  - Assets/Scripts/WorldGen/ChunkTemplate.cs
+  - Assets/Scripts/WorldGen/WorldAutotileProfile.cs
+---
+
+# TASK-0003 - Построить детерминированную генерацию мира с биомами
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Диаблоид с процедурным миром требует воспроизводимого результата по seed. Биомы влияют не только на визуал, но и на правила спавна, лута и будущих данжей.
+
+## Expected Outcome
+
+Один и тот же seed всегда строит одинаковый набор чанков, тайлов и биомных зон. У мира есть понятный API для запроса biome data и chunk data.
+
+## Current Context
+
+В проекте уже есть `InfiniteWorldGenerator`, `ChunkTemplate` и `WorldAutotileProfile`, что дает стартовую основу под генерацию 2D-мира.
+
+## Source Of Truth
+
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+- `Assets/Scripts/WorldGen/ChunkTemplate.cs`
+- решения из `TASK-0001`
+
+## Read First
+
+- `docs/tasks/items/TASK-0001.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+- `Assets/Scripts/WorldGen/ChunkTemplate.cs`
+- `Assets/Scripts/WorldGen/WorldAutotileProfile.cs`
+
+## Scope In
+
+- нормализовать seed-driven worldgen
+- определить модель биома на уровне чанка и под-областей
+- выделить стабильные world coordinates и chunk coordinates
+- подготовить world query API для спавна и данжей
+
+## Scope Out
+
+- логика врагов и битовые маски убийств
+- размещение готовых данж prefab
+
+## Constraints
+
+- генерация должна быть одинаковой для всех клиентов и сервера
+- нельзя строить ключевые правила мира только на клиенте
+
+## If You Find Drift
+
+- если существующий worldgen зависит от недетерминированных источников, это нужно исправлять или явно документировать
+
+## Suggested Approach
+
+1. Зафиксировать структуру seed, biome sampling и координатную систему.
+2. Вынести deterministic chunk generation API.
+3. Подготовить точки интеграции для spawn, saves и dungeon placement.
+
+## Acceptance Criteria
+
+- одинаковый seed порождает одинаковые чанки и биомы
+- есть способ получить biome/chunk data без прямой привязки к визуальному рендеру
+- downstream systems могут использовать мир как deterministic source of truth
+
+## Verification
+
+- прогон нескольких одинаковых seed и сравнение результатов
+- ручная проверка стабильности при повторной загрузке мира
+
+## Risks / Open Questions
+
+- потребуется решить, хранится ли биом целиком как функция seed или частично кэшируется в save
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - поддержка биомов зафиксирована как часть ядра worldgen, а не как декоративное расширение.
+
+## Handoff Notes
+
+Задачи по спавну, сохранениям и данжам должны ссылаться на deterministic world query API из этой задачи.

docs/tasks/items/TASK-0004.md

@@ -0,0 +1,110 @@
+---
+id: TASK-0004
+title: Спроектировать раздельные сохранения мира и персонажей
+summary: Зафиксировать и реализовать модель сохранений по аналогии с Terraria: отдельно данные мира, отдельно профиль игрока, с возможностью входить любым персонажем в любой мир.
+priority: High
+area: persistence
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0001
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scenes/SampleScene.unity
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+---
+
+# TASK-0004 - Спроектировать раздельные сохранения мира и персонажей
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь явно хочет модель Terraria-style. Без этого раннее проектирование инвентаря, прогрессии, выбора мира и сетевого join flow будет хрупким.
+
+## Expected Outcome
+
+Есть документированная и реализуемая структура world save и player save, описаны поля, границы владения данными и точка их загрузки/сохранения.
+
+## Current Context
+
+Системы сохранения мира, игрока и их версионирования пока не оформлены. Эта задача создает основу для enemy bitmask, инвентаря и прогрессии.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0001.md`
+- `docs/tasks/items/TASK-0002.md`
+- последующая реализация persistence layer
+
+## Read First
+
+- `docs/tasks/items/TASK-0001.md`
+- `docs/tasks/items/TASK-0002.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+
+## Scope In
+
+- определить world save schema
+- определить player profile schema
+- описать lifecycle load/save в singleplayer и multiplayer host flow
+- определить ownership и conflict rules
+
+## Scope Out
+
+- миграции между версиями save format
+- reconnect/resume после дисконнекта
+
+## Constraints
+
+- world save и player save должны быть независимыми файлами/сущностями
+- world save хранит world-state, player save хранит прогрессию и инвентарь персонажа
+
+## If You Find Drift
+
+- если в коде появится смешение player и world state, это нужно фиксировать как архитектурный drift
+
+## Suggested Approach
+
+1. Зафиксировать schema и ownership для мира и персонажа.
+2. Описать момент чтения и записи для host/server.
+3. Подготовить точку интеграции для inventory, progression и chunk kill state.
+
+## Acceptance Criteria
+
+- игрок может существовать отдельно от мира
+- мир хранит собственное состояние независимо от конкретного персонажа
+- схема не мешает любому игроку зайти в любой мир
+
+## Verification
+
+- вычитка схемы сохранений на отсутствие циклических зависимостей
+- ручная проверка сценария выбора персонажа и выбора мира как независимых шагов
+
+## Risks / Open Questions
+
+- потребуется заранее решить идентификаторы игроков и персонажей для мультиплеерного join flow
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - Terraria-style сохранения выделены в отдельную задачу перед инвентарем и enemy save state.
+
+## Handoff Notes
+
+Все persistence-задачи ниже должны ссылаться на эту схему как на базовую.

docs/tasks/items/TASK-0005.md

@@ -0,0 +1,107 @@
+---
+id: TASK-0005
+title: Реализовать детерминированный спавн врагов по чанкам
+summary: Построить систему спавна, где состав врагов в чанке строго определяется seed, координатами чанка и правилами биома.
+priority: Highest
+area: spawning
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0003
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+---
+
+# TASK-0005 - Реализовать детерминированный спавн врагов по чанкам
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь явно требует, чтобы в одном и том же чанке всегда спавнились одинаковые враги. Это ключевой контракт для save/load и синхронизации между клиентами.
+
+## Expected Outcome
+
+Для любого `(worldSeed, chunkCoord)` сервер всегда может вычислить один и тот же набор spawn slots: тип врага, позицию, уровень и другие deterministic параметры.
+
+## Current Context
+
+Мир уже разбит на чанки, но у врагов еще нет deterministic spawn layer, связанного с seed и биомами.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0003.md`
+- будущий spawn runtime code
+
+## Read First
+
+- `docs/tasks/items/TASK-0003.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+
+## Scope In
+
+- deterministic enemy roster на чанк
+- привязка к seed, biome и chunk coords
+- deterministic spawn positions внутри чанка
+- генерация стабильного enemy slot index для битовой маски жив/мертв
+
+## Scope Out
+
+- AI и боевое поведение врагов
+- сохранение kill-state после убийства
+
+## Constraints
+
+- состав врагов не должен зависеть от порядка загрузки чанков
+- клиент не должен быть каноническим источником расчета спавна
+
+## If You Find Drift
+
+- если расчет спавна использует runtime randomness без фиксированного seed, это нарушение задачи
+
+## Suggested Approach
+
+1. Определить stable enemy slot model внутри чанка.
+2. Привязать spawn rules к biome и difficulty rules.
+3. Подготовить API для совместной работы с kill-state и save system.
+
+## Acceptance Criteria
+
+- один и тот же чанк всегда получает одинаковый набор врагов
+- у каждого врага есть стабильный slot/bit index
+- система не ломается при повторной загрузке мира и чанков
+
+## Verification
+
+- повторная генерация одинакового чанка и сравнение spawn roster
+- ручная проверка нескольких биомов и разных chunk coordinates
+
+## Risks / Open Questions
+
+- нужно заранее ограничить максимальное число спавнов на чанк для удобной bitmask модели
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - детерминированный спавн выделен в отдельную задачу до kill-state persistence.
+
+## Handoff Notes
+
+При реализации закладывать стабильный `enemySlotIndex`, чтобы `TASK-0006` не потребовала пересборки формата сохранения.

docs/tasks/items/TASK-0006.md

@@ -0,0 +1,110 @@
+---
+id: TASK-0006
+title: Реализовать побитовую систему состояния врагов в чанке
+summary: Сохранить состояние врагов чанка через int или расширяемую bitmask, где каждый бит соответствует конкретному deterministic enemy slot.
+priority: Highest
+area: persistence
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0004
+  - TASK-0005
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+---
+
+# TASK-0006 - Реализовать побитовую систему состояния врагов в чанке
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь описал конкретную механику хранения enemy state через биты. Это позволяет сохранять большой мир компактно и воспроизводимо.
+
+## Expected Outcome
+
+Для каждого чанка можно хранить compact mask, из которой однозначно определяется, какие deterministic slots еще живы, а какие уже убиты и не должны спавниться повторно.
+
+## Current Context
+
+Enemy slot model должна прийти из `TASK-0005`, а общая схема world save из `TASK-0004`.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0005.md`
+- runtime code сохранений мира после внедрения
+
+## Read First
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0005.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+
+## Scope In
+
+- формат битовой маски для enemy slots
+- правила чтения и записи маски в world save
+- применение маски при загрузке и регенерации чанка
+- расширяемость на случай числа врагов больше емкости одного int
+
+## Scope Out
+
+- миграции формата сохранений между версиями
+- сложная аналитика по прогрессу зачистки мира
+
+## Constraints
+
+- индекс бита должен жестко соответствовать deterministic enemy slot
+- нельзя терять совместимость между спавном и сохранением
+
+## If You Find Drift
+
+- если реализация спавна не дает стабильного соответствия slot -> bit, нужно остановиться и исправить основу
+
+## Suggested Approach
+
+1. Определить каноническое значение бита: жив/мертв и правила инициализации.
+2. Описать сериализацию маски в world save.
+3. Применить маску при загрузке чанка до фактического spawn instantiate.
+
+## Acceptance Criteria
+
+- убийство врага меняет корректный бит в состоянии чанка
+- повторный вход в мир не возрождает уже убитых врагов
+- система поддерживает сценарий с несколькими врагами на чанк без потери детерминизма
+
+## Verification
+
+- ручной тест: убить часть врагов, сохранить мир, перезагрузить и проверить состав чанка
+- сверка битовой маски с фактически заспавненными слотами
+
+## Risks / Open Questions
+
+- нужно определить политику для чанков, где врагов больше, чем можно удобно хранить в одном `int`
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - пользовательское требование о bitmask сохранено как отдельный канонический task.
+
+## Handoff Notes
+
+Если реализация выберет не один `int`, а массив масок, нужно сохранить семантику user-facing идеи: состояние читается побитово и зависит от slot index.

docs/tasks/items/TASK-0007.md

@@ -0,0 +1,107 @@
+---
+id: TASK-0007
+title: Построить базовую боевую систему и прогрессию
+summary: Ввести общие абстракции здоровья, урона, характеристик, целей, опыта, уровней и правил роста, которые используются игроками, врагами и оружием.
+priority: Highest
+area: gameplay-core
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0001
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0007 - Построить базовую боевую систему и прогрессию
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Инвентарь, оружие, скиллы, враги и классы должны опираться на общий combat core, иначе MVP быстро распадется на несовместимые механики.
+
+## Expected Outcome
+
+Есть единый набор боевых сущностей и правил: здоровье, получение урона, базовые статы, опыт, уровни персонажа и связь уровня оружия с общими расчетами.
+
+## Current Context
+
+Сейчас в проекте нет оформленной боевой модели. Эта задача создает основу для оружия, классов, врагов и скиллов.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0001.md`
+- runtime-код combat core после внедрения
+
+## Read First
+
+- `docs/tasks/items/TASK-0001.md`
+- `Assets/Scripts/Player/SimplePlayerInputMover.cs`
+
+## Scope In
+
+- базовые характеристики и derived stats
+- здоровье, смерть, урон и targetable entities
+- опыт и уровни персонажа
+- связь уровня оружия с боевыми расчетами
+
+## Scope Out
+
+- конкретные class skills
+- UI отображение всех статов и прогресс-бара
+
+## Constraints
+
+- боевые расчеты должны быть совместимы с server-authoritative моделью
+- прогрессия оружия не должна жить отдельно от общей combat formula
+
+## If You Find Drift
+
+- если отдельные подсистемы начинают считать урон по своим правилам, это drift и его надо устранять
+
+## Suggested Approach
+
+1. Выделить общие боевые интерфейсы и runtime data.
+2. Зафиксировать формулы роста и зависимости weapon level.
+3. Подготовить точки интеграции для классов, AI и умений.
+
+## Acceptance Criteria
+
+- игрок и враг используют общую модель получения урона
+- уровень персонажа и уровень оружия влияют на расчеты по явным правилам
+- downstream системы могут переиспользовать combat core без дублирования формул
+
+## Verification
+
+- ручная проверка базового обмена уроном между двумя сущностями
+- вычитка формул прогрессии и зависимостей weapon level
+
+## Risks / Open Questions
+
+- потребуется быстро решить, какие статы нужны в MVP, чтобы не перегрузить систему
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - требования по уровням персонажа и оружия объединены в один combat-core task.
+
+## Handoff Notes
+
+Все задачи по оружию, скиллам и врагам должны использовать единый combat core из этой задачи.

docs/tasks/items/TASK-0008.md

@@ -0,0 +1,109 @@
+---
+id: TASK-0008
+title: Реализовать сетевой инвентарь и экипировку
+summary: Сделать инвентарь персонажа с сетевой синхронизацией, слотами, стаками, переносом предметов и экипировкой.
+priority: Highest
+area: inventory
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0004
+  - TASK-0007
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0008 - Реализовать сетевой инвентарь и экипировку
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Инвентарь является обязательным требованием MVP и базой для оружия, книг скиллов, лута и сохранения прогресса персонажа.
+
+## Expected Outcome
+
+Персонаж имеет сетевой инвентарь и слоты экипировки, которые корректно сохраняются в player save и синхронизируются через сервер.
+
+## Current Context
+
+Система предметов и инвентаря пока отсутствует. Требования по разделению player/world saves уже вынесены в `TASK-0004`.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0007.md`
+- runtime inventory implementation
+
+## Read First
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0007.md`
+
+## Scope In
+
+- inventory slots и item stacks
+- equip slots для оружия и связанных предметов
+- сетевые операции перемещения и использования предметов
+- сохранение inventory state в player save
+
+## Scope Out
+
+- полный UI polish для inventory
+- торговля между игроками
+
+## Constraints
+
+- сервер валидирует изменения инвентаря
+- инвентарь живет в player save, а не в world save
+
+## If You Find Drift
+
+- если предметы начинают храниться только в runtime world session без связи с player save, это drift
+
+## Suggested Approach
+
+1. Определить item model и inventory slot model.
+2. Добавить equip slots и сетевые команды изменения состояния.
+3. Связать систему с persistence layer и будущими книгами/оружием.
+
+## Acceptance Criteria
+
+- предметы можно положить в инвентарь, переместить и экипировать
+- состояние инвентаря сохраняется вместе с персонажем
+- сетевые операции не позволяют клиенту самовольно подменять server state
+
+## Verification
+
+- ручная проверка equip/unequip и перетаскивания предметов
+- проверка сохранения и повторной загрузки player inventory
+
+## Risks / Open Questions
+
+- потребуется рано выбрать, поддерживаются ли частичные стаки книг и расходников в MVP
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - инвентарь зафиксирован как отдельная сетево-персистентная подсистема, а не только UI.
+
+## Handoff Notes
+
+Оружие и книги должны входить в общий item model, а не жить отдельными ad-hoc сущностями.

docs/tasks/items/TASK-0009.md

@@ -0,0 +1,109 @@
+---
+id: TASK-0009
+title: Ввести абстрактную систему оружия
+summary: Реализовать общую модель оружия с базовыми параметрами, уровнем, типом атаки и точками расширения для разных классов и вставляемых скиллов.
+priority: Highest
+area: equipment
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0007
+  - TASK-0008
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0009 - Ввести абстрактную систему оружия
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь требует абстрактное оружие. Оно должно быть совместимо с инвентарем, уровнями, классами и книгами скиллов.
+
+## Expected Outcome
+
+Есть канонический weapon contract: общие параметры, level scaling, attack execution hooks и слот(ы) для встроенных skill books.
+
+## Current Context
+
+Оружия пока нет. Его нельзя проектировать отдельно от боевой модели и инвентаря.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0008.md`
+- runtime weapon implementation
+
+## Read First
+
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0008.md`
+
+## Scope In
+
+- абстрактная база оружия
+- общие боевые параметры и level scaling
+- execution hooks для удара, выстрела, каста и модификаторов
+- связь оружия с inventory/equip и skill sockets
+
+## Scope Out
+
+- реализация конкретных class skills
+- контентное разнообразие десятков weapon archetypes
+
+## Constraints
+
+- оружие должно использовать общую combat formula
+- weapon runtime не должен дублировать систему навыков или инвентаря
+
+## If You Find Drift
+
+- если разные типы оружия начнут обходить общую базу и считать урон отдельно, это drift
+
+## Suggested Approach
+
+1. Выделить `WeaponDefinition` и `WeaponRuntime` уровни.
+2. Зафиксировать common attack contract и level scaling.
+3. Подготовить слоты под книги/скиллы без избыточной специализации.
+
+## Acceptance Criteria
+
+- есть единый базовый контракт оружия
+- уровень оружия влияет на боевые расчеты по правилам из combat core
+- оружие может быть экипировано персонажем через inventory/equipment layer
+
+## Verification
+
+- ручная проверка базового выполнения weapon action
+- вычитка интеграции с inventory и progression
+
+## Risks / Open Questions
+
+- потребуется быстро решить, хранится ли skill socket внутри самого weapon item или в отдельном equipment state
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - уровень оружия включен в базовый weapon task, а не вынесен отдельно.
+
+## Handoff Notes
+
+Class skill задачи ниже должны использовать этот weapon contract как обязательную базу.

docs/tasks/items/TASK-0010.md

@@ -0,0 +1,109 @@
+---
+id: TASK-0010
+title: Реализовать абстрактную систему скиллов и книг для оружия
+summary: Построить общую модель скиллов и книг, которые вставляются в оружие и добавляют или модифицируют активные способности.
+priority: Highest
+area: abilities
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0008
+  - TASK-0009
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0010 - Реализовать абстрактную систему скиллов и книг для оружия
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь хочет абстрактные скиллы, которые вставляются в оружие через книги. Это ключевая ось билдов и расширяемости класса/оружия.
+
+## Expected Outcome
+
+Есть единая skill system с runtime execution contract, socket/book model и правилами подключения скилла к оружию и его активации в бою.
+
+## Current Context
+
+Боевой core, inventory и weapon abstraction должны существовать раньше. Эта задача создает общий слой до конкретных классовых MVP-умений.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+- runtime skill/book implementation
+
+## Read First
+
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+
+## Scope In
+
+- skill contract и lifecycle выполнения
+- skill book как item и источник встраиваемой способности
+- weapon sockets / attach rules
+- сетевое выполнение и базовые cooldown/resource hooks
+
+## Scope Out
+
+- широкий набор контента навыков
+- визуальные эффекты и polish для каждого умения
+
+## Constraints
+
+- скилл должен быть reusable как для игрока, так и для врага
+- книга не должна обходить server validation при установке в оружие
+
+## If You Find Drift
+
+- если навыки игрока и врага начнут жить в разных несовместимых системах, это drift
+
+## Suggested Approach
+
+1. Выделить общий runtime contract навыка.
+2. Связать skill books с item/inventory и weapon sockets.
+3. Подготовить базу для классовых MVP-умений и enemy reuse.
+
+## Acceptance Criteria
+
+- книгу можно хранить как item и вставлять в подходящее оружие
+- оружие получает активную способность через книгу по единым правилам
+- одна и та же skill system пригодна для врагов и игроков
+
+## Verification
+
+- ручная проверка установки книги в оружие и активации способности
+- вычитка контрактов player/enemy reuse
+
+## Risks / Open Questions
+
+- нужно определить, есть ли в MVP ограничения по типам оружия для конкретных книг
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - книги навыков зафиксированы как часть item/equipment flow, а не как отдельный menu-only unlock.
+
+## Handoff Notes
+
+Конкретные классовые MVP-навыки должны реализовываться поверх этой системы, без обходных исключений.

docs/tasks/items/TASK-0011.md

@@ -0,0 +1,114 @@
+---
+id: TASK-0011
+title: Сделать базовую модель классов персонажей
+summary: Подготовить общую систему классов персонажей и канонические точки различия для Воина, Мага и Лучника в MVP.
+priority: High
+area: characters
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0007
+  - TASK-0008
+  - TASK-0009
+  - TASK-0010
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0011 - Сделать базовую модель классов персонажей
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Нужен общий классовый каркас, чтобы Воин, Маг и Лучник были не тремя отдельными исключениями, а вариациями одной системы.
+
+## Expected Outcome
+
+Есть базовая модель персонажа, где класс задает стартовые параметры, совместимые archetype-ограничения и стартовый набор оружия/скиллов для MVP.
+
+## Current Context
+
+Пока нет классового слоя. Конкретные умения по классам вынесены в отдельные задачи ниже.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+
+## Scope In
+
+- базовая class definition для персонажа
+- стартовые параметры и ограничения экипировки
+- выбор класса в рамках player profile
+- точки расширения для классовых навыков MVP
+
+## Scope Out
+
+- глубокие talent trees
+- десятки классов и subclass-системы
+
+## Constraints
+
+- различия классов должны строиться поверх общих систем, а не через форки кода
+- выбор класса должен сохраняться в player save
+
+## If You Find Drift
+
+- если class-specific код начинает обходить общую weapon/skill system, это drift
+
+## Suggested Approach
+
+1. Определить базовую class definition модель.
+2. Связать класс со стартовыми характеристиками и стартовым loadout.
+3. Подготовить интеграцию с character selection menu и отдельными skill tasks.
+
+## Acceptance Criteria
+
+- в системе существуют Воин, Маг и Лучник как валидные классы персонажа
+- класс влияет на стартовую конфигурацию без дублирования core systems
+- класс можно выбрать и сохранить в player profile
+
+## Verification
+
+- ручная проверка создания персонажей трех классов
+- вычитка, что классы не ломают абстракции оружия и скиллов
+
+## Risks / Open Questions
+
+- нужно определить, насколько жестко класс ограничивает тип оружия в MVP
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - общий классовый каркас выделен до конкретных отдельных навыков Воина, Мага и Лучника.
+
+## Handoff Notes
+
+Следующие три задачи должны реализовывать MVP-навыки классов без расширения рамок beyond MVP.

docs/tasks/items/TASK-0012.md

@@ -0,0 +1,113 @@
+---
+id: TASK-0012
+title: Построить систему врагов на NavMesh с использованием скиллов
+summary: Реализовать врагов, которые перемещаются по NavMesh, выбирают цели и применяют общую систему навыков, совместимую с игроком.
+priority: Highest
+area: ai
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d6h
+depends_on:
+  - TASK-0005
+  - TASK-0007
+  - TASK-0010
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+  - Assets/Scenes/SampleScene.unity
+---
+
+# TASK-0012 - Построить систему врагов на NavMesh с использованием скиллов
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь требует врагов на NavMesh, которые могут применять те же скиллы, что и игрок. Это одна из ключевых MVP-механик боя.
+
+## Expected Outcome
+
+Враги умеют находить путь, выбирать цель, входить в боевой радиус и применять навыки через общую skill system под server authority.
+
+## Current Context
+
+Ни AI, ни вражеский runtime слой пока не оформлены. Детеминированный spawn и skill system должны быть готовы раньше.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0005.md`
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0010.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0005.md`
+- `docs/tasks/items/TASK-0007.md`
+- `docs/tasks/items/TASK-0010.md`
+- `Assets/Scenes/SampleScene.unity`
+
+## Scope In
+
+- базовый enemy actor runtime
+- NavMesh-based перемещение и target selection
+- использование общих skills и cooldown logic
+- интеграция с spawn и death state
+
+## Scope Out
+
+- сложные behavior trees
+- продвинутые boss mechanics
+
+## Constraints
+
+- AI должен работать под server authority
+- враг должен использовать ту же skill contract систему, что и игрок
+
+## If You Find Drift
+
+- если для врагов появится отдельная несовместимая ability system, это drift
+
+## Suggested Approach
+
+1. Определить базовый enemy actor и state machine.
+2. Связать его с NavMesh movement и target rules.
+3. Подключить общую skill execution model и обработку смерти.
+
+## Acceptance Criteria
+
+- враг способен найти цель и двигаться к ней через NavMesh
+- враг способен применять навык из общей ability system
+- убийство врага корректно уходит в chunk kill-state
+
+## Verification
+
+- ручной тест с врагом, преследующим игрока и применяющим навык
+- проверка интеграции смерти врага с persistence state чанка
+
+## Risks / Open Questions
+
+- на tile/grid мире нужно заранее проверить, как лучше готовить NavMesh для процедурных чанков
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - enemy AI и reuse skill system объединены в один highest-priority task.
+
+## Handoff Notes
+
+В MVP достаточно простого AI loop, если он не ломает server authority и reuse ability contract.

docs/tasks/items/TASK-0013.md

@@ -0,0 +1,112 @@
+---
+id: TASK-0013
+title: Реализовать меню лобби, выбор персонажа и выбор мира
+summary: Сделать пользовательский flow входа: подключение в лобби, выбор или создание персонажа, выбор мира и запуск игровой сессии.
+priority: High
+area: ui
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0002
+  - TASK-0004
+  - TASK-0011
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scenes/SampleScene.unity
+---
+
+# TASK-0013 - Реализовать меню лобби, выбор персонажа и выбор мира
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь явно просит меню с подключением в лобби и выбором персонажа. Это пользовательский вход в систему раздельных сохранений и сетевого bootstrap.
+
+## Expected Outcome
+
+Есть рабочий UX flow: открыть игру, подключиться, выбрать или создать персонажа, выбрать мир и войти в сессию без ручной сцены/отладки.
+
+## Current Context
+
+Пока нет оформленного меню и экранов выбора. Network bootstrap и character model должны существовать раньше.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0011.md`
+- `Assets/Scenes/SampleScene.unity`
+
+## Scope In
+
+- экран подключения и лобби
+- выбор или создание персонажа
+- выбор мира из доступных сохранений
+- запуск игровой сессии из UI
+
+## Scope Out
+
+- social UI, чат, друзья и сложный браузер серверов
+- детальный UI инвентаря и прогрессии в бою
+
+## Constraints
+
+- menu flow должен соответствовать модели player/world separation
+- UI не должен брать на себя server-authoritative решения
+
+## If You Find Drift
+
+- если UI начнет напрямую менять данные мира или персонажа в обход доменной логики, это drift
+
+## Suggested Approach
+
+1. Описать последовательность экранов и входных данных.
+2. Привязать UI к network bootstrap и save selection.
+3. Проверить сценарий создания персонажа и входа в любой мир.
+
+## Acceptance Criteria
+
+- пользователь может пройти путь от запуска игры до входа в мир через UI
+- выбор персонажа и выбор мира являются независимыми шагами
+- flow работает как для host, так и для клиента в рамках MVP
+
+## Verification
+
+- ручной проход всех экранов в happy-path сценарии
+- проверка, что один и тот же персонаж может входить в разные миры
+
+## Risks / Open Questions
+
+- потребуется решить, нужен ли отдельный экран создания мира или достаточно списка и кнопки create
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - menu flow зафиксирован как отдельная задача после network bootstrap и class model.
+
+## Handoff Notes
+
+Сначала нужен рабочий функциональный flow без избыточного UI-polish.

docs/tasks/items/TASK-0014.md

@@ -0,0 +1,111 @@
+---
+id: TASK-0014
+title: Реализовать MVP-скилл Воина с ударом мечом
+summary: Добавить для Воина минимальный рабочий навык ближней атаки мечом на базе общей weapon и skill системы.
+priority: High
+area: classes
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0009
+  - TASK-0010
+  - TASK-0011
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0014 - Реализовать MVP-скилл Воина с ударом мечом
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Для MVP нужен конкретный рабочий skill loop Воина. Он должен быть простым, но полностью проходить через общие абстракции оружия и навыков.
+
+## Expected Outcome
+
+Воин может выполнить базовый melee-удар мечом, который использует общую систему навыков, наносит урон, учитывает weapon level и работает в сетевой игре.
+
+## Current Context
+
+Эта задача зависит от готового class framework и общей skill/weapon architecture. Она не должна обходить их ради быстроты.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Scope In
+
+- базовая skill execution для melee slash
+- hit detection и применение урона
+- связь навыка с мечом как weapon archetype
+- сетевое выполнение под server authority
+
+## Scope Out
+
+- комбо-система
+- сложные parry/guard mechanics
+
+## Constraints
+
+- навык должен использовать общий skill contract
+- нельзя делать уникальную боевую логику Воина в обход weapon abstraction
+
+## If You Find Drift
+
+- если melee skill потребует сломать общую skill system, нужно исправлять базовую систему, а не делать исключение
+
+## Suggested Approach
+
+1. Подготовить weapon archetype меча для Воина.
+2. Реализовать простой melee skill через общую skill execution pipeline.
+3. Проверить урон, дистанцию и сетевое воспроизведение.
+
+## Acceptance Criteria
+
+- Воин может бить мечом как отдельным MVP-скиллом
+- удар наносит урон в ближней зоне по общим правилам боя
+- навык работает в мультиплеере и совместим с weapon level
+
+## Verification
+
+- ручной тест удара по врагу и/или цели
+- проверка сетевой синхронизации результата удара
+
+## Risks / Open Questions
+
+- нужно определить, делать ли удар конусом, коротким рейкастом или overlap hitbox в MVP
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - MVP-умение Воина вынесено в отдельную реализационную задачу по запросу пользователя.
+
+## Handoff Notes
+
+Если понадобится анимационный polish, это не должно блокировать базовую серверную механику удара.

docs/tasks/items/TASK-0015.md

@@ -0,0 +1,111 @@
+---
+id: TASK-0015
+title: Реализовать MVP-скилл Мага с AOE-кастом
+summary: Добавить для Мага минимальный рабочий AOE-скилл на базе общей системы навыков и оружия.
+priority: High
+area: classes
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0009
+  - TASK-0010
+  - TASK-0011
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0015 - Реализовать MVP-скилл Мага с AOE-кастом
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Для MVP нужен кастерский пример навыка, отличающийся от ближнего удара Воина и показывающий, что общая система поддерживает area-based эффекты.
+
+## Expected Outcome
+
+Маг может применить условный AOE-скилл, который выбирает область, наносит урон в зоне и работает через общий skill pipeline и сетевую валидацию.
+
+## Current Context
+
+Как и другие классовые MVP-навыки, этот task должен использовать уже готовые combat, weapon и skill abstraction слои.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Scope In
+
+- базовый AOE cast skill
+- выбор точки или области применения
+- нанесение урона нескольким целям в зоне
+- сетевое выполнение и общие cooldown/resource hooks
+
+## Scope Out
+
+- chain spells и сложные статусные эффекты
+- полноценная система mana economy beyond MVP
+
+## Constraints
+
+- навык должен использовать общий skill contract
+- область эффекта должна валидироваться сервером
+
+## If You Find Drift
+
+- если AOE-код начинает жить отдельно от общей ability system, это drift
+
+## Suggested Approach
+
+1. Подготовить weapon archetype или cast-source для Мага.
+2. Реализовать базовый AOE skill через общую execution pipeline.
+3. Проверить обработку нескольких целей и сетевую корректность.
+
+## Acceptance Criteria
+
+- Маг может применить AOE-скилл как отдельный MVP-скилл
+- навык наносит урон всем валидным целям в зоне
+- навык корректно работает в мультиплеере под server authority
+
+## Verification
+
+- ручной тест AOE по группе целей
+- проверка синхронизации визуального и фактического результата в сети
+
+## Risks / Open Questions
+
+- нужно выбрать MVP-форму зоны: круг, квадрат или мгновенная область по тайлам/юнитам
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - MVP-умение Мага вынесено в отдельную задачу по явному запросу пользователя.
+
+## Handoff Notes
+
+Если система ресурсов для каста еще не готова, можно временно использовать cooldown-only модель, но без обхода общей skill architecture.

docs/tasks/items/TASK-0016.md

@@ -0,0 +1,111 @@
+---
+id: TASK-0016
+title: Реализовать MVP-скилл Лучника с выстрелом
+summary: Добавить для Лучника минимальный рабочий навык выстрела из оружия на базе общей weapon и skill системы.
+priority: High
+area: classes
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0009
+  - TASK-0010
+  - TASK-0011
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/Player/SimplePlayerInputMover.cs
+---
+
+# TASK-0016 - Реализовать MVP-скилл Лучника с выстрелом
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Для MVP нужен ranged-пример навыка, чтобы система покрывала ближний бой, AOE и направленный выстрел.
+
+## Expected Outcome
+
+Лучник может выполнить базовый выстрел, который выпускает projectile или другой канонический ranged attack и применяет урон через общие правила боя.
+
+## Current Context
+
+Этот task должен использовать готовые abstractions оружия, навыков и классов. Он не должен вводить отдельную систему стрельбы мимо общей архитектуры.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+- `docs/tasks/items/TASK-0011.md`
+
+## Scope In
+
+- базовый ranged attack skill
+- запуск projectile или эквивалентного попадания по направлению
+- применение урона по общей combat model
+- сетевое выполнение и репликация результата
+
+## Scope Out
+
+- разные типы стрел и зарядка выстрела
+- сложная баллистика и penetration mechanics
+
+## Constraints
+
+- навык должен использовать общую skill contract систему
+- траектория и попадание должны валидироваться сервером
+
+## If You Find Drift
+
+- если ranged attack начнет жить как отдельный ad-hoc input path вне общей ability system, это drift
+
+## Suggested Approach
+
+1. Подготовить bow/ranged weapon archetype.
+2. Реализовать выстрел как skill execution поверх weapon contract.
+3. Проверить попадание, урон и сетевое воспроизведение.
+
+## Acceptance Criteria
+
+- Лучник может стрелять как отдельным MVP-скиллом
+- выстрел наносит урон валидной цели по общим боевым правилам
+- навык корректно синхронизируется в мультиплеере
+
+## Verification
+
+- ручной тест выстрела по цели
+- проверка server-authoritative обработки попадания
+
+## Risks / Open Questions
+
+- нужно определить, использовать ли в MVP физический projectile или hitscan-подобный упрощенный путь
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - MVP-умение Лучника вынесено в отдельную задачу по явному запросу пользователя.
+
+## Handoff Notes
+
+Если projectile path окажется слишком дорогим для первого прохода, допустимо начать с упрощенного ranged hit model при сохранении того же публичного контракта.

docs/tasks/items/TASK-0017.md

@@ -0,0 +1,110 @@
+---
+id: TASK-0017
+title: Добавить reconnect/resume после дисконнекта с сохранением позиции
+summary: Реализовать BackLog-задачу на восстановление игрока после дисконнекта с возвратом в мир и сохранением позиции, состояния и привязки к сессии.
+priority: Medium
+area: networking
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0002
+  - TASK-0004
+  - TASK-0013
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scenes/SampleScene.unity
+---
+
+# TASK-0017 - Добавить reconnect/resume после дисконнекта с сохранением позиции
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Reconnect/resume нужен для более устойчивого кооператива, но не блокирует первый MVP. Поэтому задача вынесена в `BackLog`.
+
+## Expected Outcome
+
+Игрок после дисконнекта может вернуться в ту же сессию и получить корректное восстановление позиции и session-relevant state без дублирования персонажа.
+
+## Current Context
+
+Сначала должны появиться рабочие flow подключения, выбор мира и базовые сохранения игрока/мира.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0013.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0013.md`
+
+## Scope In
+
+- reconnect flow после временного разрыва связи
+- сохранение и восстановление позиции персонажа
+- предотвращение duplicate player session
+- базовые timeout/resume rules
+
+## Scope Out
+
+- полнофункциональный drop-in/drop-out service layer
+- миграция сессии между серверами
+
+## Constraints
+
+- восстановление не должно ломать server authority
+- session resume должен уважать разделение player/world saves
+
+## If You Find Drift
+
+- если базовый join flow не готов, задача остается в `BackLog` и не тянет за собой преждевременные костыли
+
+## Suggested Approach
+
+1. Определить session resume token или эквивалентный идентификатор возврата.
+2. Описать правила сохранения позиции и временного session state.
+3. Реализовать безопасный reconnect без дублей персонажа.
+
+## Acceptance Criteria
+
+- игрок может переподключиться после дисконнекта и продолжить с близкой сохраненной позиции
+- в мире не остается дублированных экземпляров персонажа
+- reconnect flow не ломает существующий lobby/world selection pipeline
+
+## Verification
+
+- ручной сценарий: подключиться, сместиться, разорвать связь, переподключиться, проверить resume
+
+## Risks / Open Questions
+
+- нужно определить, хранится ли позиция resume в player save, world session state или в отдельном session cache
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - задача добавлена в `BackLog` по явному запросу пользователя.
+
+## Handoff Notes
+
+Не поднимать приоритет до готовности базового сетевого flow и persistence layer.

docs/tasks/items/TASK-0018.md

@@ -0,0 +1,108 @@
+---
+id: TASK-0018
+title: Добавить миграции формата сохранений между версиями
+summary: Реализовать BackLog-задачу на версионирование save format и безопасные миграции world save и player save между версиями проекта.
+priority: Medium
+area: persistence
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0004
+  - TASK-0006
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+---
+
+# TASK-0018 - Добавить миграции формата сохранений между версиями
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Миграции save format важны для долгоживущего проекта, но не блокируют первый MVP. Поэтому задача вынесена в `BackLog`.
+
+## Expected Outcome
+
+Система сохранений имеет version field и pipeline миграций, позволяющий безопасно читать старые world/player save после изменений схемы.
+
+## Current Context
+
+Базовая схема сохранений и enemy bitmask должны быть определены раньше. Иначе мигрировать будет нечего.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0006.md`
+- future save schema docs
+
+## Read First
+
+- `docs/tasks/items/TASK-0004.md`
+- `docs/tasks/items/TASK-0006.md`
+
+## Scope In
+
+- versioning для world/player save
+- up-migration pipeline
+- базовые правила обратной совместимости чтения
+- обработка ошибок и fallback policy
+
+## Scope Out
+
+- cross-game import/export tools
+- поддержка всех исторических pre-release форматов без ограничений
+
+## Constraints
+
+- миграции не должны молча повреждать данные
+- player и world save мигрируются независимо, но по общим правилам versioning
+
+## If You Find Drift
+
+- если save schema меняется без version bump, это нарушение задачи
+
+## Suggested Approach
+
+1. Добавить version field в save schemas.
+2. Описать up-migration pipeline по шагам версий.
+3. Подготовить тестовые старые примеры сохранений для проверки.
+
+## Acceptance Criteria
+
+- save format имеет версию
+- старый save может быть прочитан и мигрирован в текущую схему
+- ошибки миграции не приводят к тихой потере world/player state
+
+## Verification
+
+- ручной тест чтения старого save fixture после изменения схемы
+
+## Risks / Open Questions
+
+- нужно определить политику для несовместимых breaking changes worldgen или enemy slot layout
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - задача добавлена в `BackLog` по явному запросу пользователя.
+
+## Handoff Notes
+
+Пока задача в `BackLog`, новые persistence changes все равно должны по возможности закладывать version field заранее.

docs/tasks/items/TASK-0019.md

@@ -0,0 +1,110 @@
+---
+id: TASK-0019
+title: Добавить генерацию данжей-предфабов поверх биомов мира
+summary: Реализовать BackLog-задачу на детерминированное размещение готовых dungeon prefab в мире так, чтобы они одинаково вставлялись по seed, вписывались в grid и вырезали мировой слой под собой.
+priority: High
+area: worldgen
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d6h
+depends_on:
+  - TASK-0003
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs
+  - Assets/ChunkTemplate.asset
+---
+
+# TASK-0019 - Добавить генерацию данжей-предфабов поверх биомов мира
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Пользователь явно описал сценарий с готовым prefab-данжем, который должен одинаково размещаться у всех игроков и не рисоваться поверх карты, а встраиваться в grid мира с вырезанием тайлов под собой.
+
+## Expected Outcome
+
+Система worldgen умеет по seed и biome rules выбрать место для dungeon prefab, встроить его в мир, удалить конфликтующий мировой слой под ним и воспроизвести тот же результат у всех клиентов.
+
+## Current Context
+
+В проекте уже есть grid/tile-based worldgen. Dungeon placement должен строиться поверх deterministic world coordinates и biome sampling.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0003.md`
+- готовые dungeon prefab assets
+- future dungeon placement code
+
+## Read First
+
+- `docs/tasks/items/TASK-0003.md`
+- `Assets/Scripts/WorldGen/InfiniteWorldGenerator.cs`
+- `Assets/ChunkTemplate.asset`
+
+## Scope In
+
+- deterministic placement dungeon prefab по seed и biome rules
+- привязка prefab к grid/tiles мира
+- вырезание или замещение мировых тайлов под данжем
+- одинаковое размещение у всех игроков
+
+## Scope Out
+
+- процедурная сборка самих данжей из модулей
+- сложная логика лута и боссов внутри данжа
+
+## Constraints
+
+- данж не должен просто отрисовываться сверху без интеграции в мир
+- размещение должно быть детерминированным и совместимым с chunked worldgen
+
+## If You Find Drift
+
+- если prefab placement требует недетерминированного ручного runtime-подбора, это drift
+
+## Suggested Approach
+
+1. Определить правила выбора позиции данжа по biome/world rules.
+2. Описать grid-aligned placement и carve/replace world tiles под prefab.
+3. Подготовить интеграцию с chunk loading и world save.
+
+## Acceptance Criteria
+
+- один и тот же seed размещает один и тот же dungeon prefab в одном и том же месте
+- данж встраивается в grid мира и заменяет конфликтующие тайлы под собой
+- результат одинаков у всех игроков и повторяем после загрузки мира
+
+## Verification
+
+- повторная генерация одинакового мира и сверка положения данжа
+- ручная проверка отсутствия наложения поверх неснятых мировых тайлов
+
+## Risks / Open Questions
+
+- нужно решить, как хранить пересечение данжа с несколькими чанками и как кэшировать carve results
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - задача добавлена в `BackLog` по явному запросу пользователя и уточнена требованием grid-carving.
+
+## Handoff Notes
+
+При переводе в `ToDo` желательно отдельно перечислить доступные dungeon prefab и biome placement rules.

docs/tasks/items/TASK-0020.md

@@ -0,0 +1,113 @@
+---
+id: TASK-0020
+title: Добавить серверные ограничения и валидации против читов
+summary: Реализовать BackLog-задачу на server-side validation сетевых команд, защиту от некорректных клиентских состояний и базовые античит-ограничения для MVP.
+priority: High
+area: security
+owner: unassigned
+created: 2026-03-30
+updated: 2026-03-30
+execution_time: 1d
+depends_on:
+  - TASK-0002
+  - TASK-0008
+  - TASK-0009
+  - TASK-0010
+canonical_docs:
+  - docs/tasks/Index.md
+related_files:
+  - Assets/Scenes/SampleScene.unity
+---
+
+# TASK-0020 - Добавить серверные ограничения и валидации против читов
+
+## Status
+
+Статус задачи ведется в `docs/tasks/Index.md` и является каноническим там.
+
+Допустимые значения статуса:
+
+- `BackLog`
+- `ToDo`
+- `InProgress`
+- `Review`
+- `Done`
+
+## Why
+
+Даже для MVP нельзя полностью доверять клиенту в вопросах перемещения, инвентаря, применения оружия и навыков. Базовые валидации должны существовать на сервере.
+
+## Expected Outcome
+
+Сервер проверяет основные клиентские команды и не принимает некорректные действия: невозможное перемещение, запрещенное использование предметов, недопустимую установку книг, фальшивые попадания и другие очевидные нарушения.
+
+## Current Context
+
+На раннем этапе достаточно базовых ограничений. Полноценный античит не нужен для первого MVP, поэтому задача в `BackLog`.
+
+## Source Of Truth
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+
+## Read First
+
+- `docs/tasks/items/TASK-0002.md`
+- `docs/tasks/items/TASK-0008.md`
+- `docs/tasks/items/TASK-0009.md`
+- `docs/tasks/items/TASK-0010.md`
+
+## Scope In
+
+- validation для movement и interaction commands
+- validation для inventory/equipment изменений
+- validation для использования оружия и навыков
+- базовые rate limits и sanity checks
+
+## Scope Out
+
+- полноценная внешняя античит-служба
+- поведенческий анализ и ban pipeline
+
+## Constraints
+
+- сервер остается источником истины для state transitions
+- проверки должны быть дешевыми и не ломать игровой loop MVP
+
+## If You Find Drift
+
+- если новые команды добавляются без server-side validation, это drift
+
+## Suggested Approach
+
+1. Перечислить критичные клиентские команды по подсистемам.
+2. Добавить server-side guards и rejection rules.
+3. Подготовить базовое логирование отказов и подозрительных случаев.
+
+## Acceptance Criteria
+
+- сервер отклоняет очевидно неверные клиентские действия
+- inventory, weapon и skill команды валидируются по server state
+- система не позволяет клиенту самовольно изменять критичные runtime states
+
+## Verification
+
+- ручная проверка некорректных сценариев через debug commands или подмену входных данных
+
+## Risks / Open Questions
+
+- нужно определить минимальный набор проверок, который даст наибольшую ценность без сильного замедления разработки MVP
+
+## Human Decisions Needed
+
+- none currently
+
+## Decision Log
+
+- `2026-03-30` - задача добавлена в `BackLog` по явному запросу пользователя.
+
+## Handoff Notes
+
+Даже до выполнения этой задачи новые сетевые команды желательно проектировать так, чтобы их было легко валидировать на сервере.