VanguardReMaster/docs/Development/IMPLEMENTATION_PLAN.md

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
• путь к файлу (если известен);
• класс/метод (если существует);
• конкретная логика;
• причина изменения;
• ожидаемый результат;
• зависимости от других пунктов;
• Реализация: не выполнена;
• Проверка: не выполнена.

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

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

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

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

E. Проверки

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

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

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

G. Результат

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