# Implementation Plan

Активный журнал задач и планов изменений. Постоянные правила проекта хранятся
в Skill `vanguard-remaster`; история старых блоков — в `IMPLEMENTATION_CHECKLIST.md`,
`DEVELOPMENT_CHECKLIST.md` и `docs/HANDOFF.md`. Этот файл не заменяет их и не
является источником игровых правил.

## Процесс

1. **DeepSeek** анализирует пожелание, код и зависимости, задаёт вопросы и
   создаёт/обновляет раздел задачи. Игровой код на этом этапе не меняется.
2. **Kimi** читает `AGENTS.md`, Skill и раздел задачи, сверяет план с текущим
   кодом, реализует, проверяет и обновляет статусы.
3. Передача — только через файлы репозитория и Git. Память модели и чат не
   считаются общим контекстом.
4. Если план устарел или требования изменились, Kimi останавливает зависимую
   часть, фиксирует причину и при необходимости возвращает задачу на анализ.
5. Нельзя удалять чужие задачи, невыполненные пункты и историю статусов.

Подробный процесс — `docs/Development/AGENT-WORKFLOW.md`.

## Статусы

- `[ ]` — не выполнено;
- `[x]` — выполнено и подтверждено доступными проверками;
- `[!]` — заблокировано или ждёт решения;
- `[-]` — больше не требуется после согласованного изменения плана.

Для каждого пункта храни отдельно:

- **Реализация:** выполнена / не выполнена / не требуется.
- **Проверка:** выполнена (что именно) / не выполнена (почему).

`[x]` нельзя ставить, если реализация есть, а проверка не запускалась.

## Журнал задач

| ID | Статус | Название | Фаза | Проверка |
|---|---|---|---|---|
| — | — | Нет активных задач | — | — |

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

---

## Шаблон задачи (не является активной задачей)

### TASK-YYYY-NNN — краткое название

- **Статус:** `[ ]`
- **Создано:** YYYY-MM-DD
- **Анализ:** DeepSeek
- **Реализация:** Kimi
- **Затронутые системы:** ...

#### A. Цель и требования

- Что просит пользователь.
- Ожидаемое поведение.
- Обязательные правила Skill.
- Ограничения, которые нельзя нарушать.
- Критерии готовности.

#### B. Текущее состояние

- Как работает сейчас.
- Какие системы и файлы проверены.
- Существующие механики, которые нужно сохранить.
- Подтверждённые факты и открытые вопросы.

#### C. Чек-лист изменений

Каждый пункт:

- `[ ]` `MODIFY` / `CREATE` / `DELETE` / `TEST` / `VERIFY`
- путь к файлу (если известен);
- класс/метод (если существует);
- конкретная логика;
- причина изменения;
- ожидаемый результат;
- зависимости от других пунктов;
- **Реализация:** не выполнена;
- **Проверка:** не выполнена.

Пример формата:

```text
- [ ] MODIFY `client/Assets/.../BattleView.cs` — `BattleView.SomeMethod`
  Логика: ...
  Причина: ...
  Результат: ...
  Зависит от: ...
  Реализация: не выполнена
  Проверка: не выполнена
```

#### D. Последовательность выполнения

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

#### E. Проверки

- Какие тесты/команды доступны и подтверждены проектом.
- Какие механики проверить на регрессию.
- Критерии готовности.
- Что остаётся на ручную проверку пользователя.

#### F. Риски и неизвестные вопросы

- Противоречия и побочные эффекты.
- Вопросы, требующие ответа пользователя.
- Что нельзя реализовывать до ответа.

#### G. Результат

- **Реализовано:** ...
- **Проверки:** ...
- **Не завершено/заблокировано:** ...
- **Skill обновлён:** да/нет, почему.
- **Git:** commit hash, изменённые файлы.