# Процесс DeepSeek → Kimi

Двухэтапный процесс для задач, которые меняют игру, клиент, сервер, контент или
инфраструктуру. Он нужен, потому что анализ и реализация могут выполняться
разными моделями и в разных сессиях OpenCode. Общий контекст — только файлы
репозитория и Git, не память модели.

## 1. Роли

### DeepSeek — анализ и план

- Читает `AGENTS.md`, Skill `vanguard-remaster`, `docs/SESSION-STATE.md`,
  `docs/HANDOFF.md` и связанный код.
- Изучает историю, договорённости и существующую реализацию.
- Задаёт вопросы через инструмент `question`, если без ответа нельзя
  корректно спланировать изменение.
- Создаёт или обновляет раздел задачи в `docs/Development/IMPLEMENTATION_PLAN.md`.
- **Не изменяет игровой код, сцены, префабы, ScriptableObject и конфиги.**
- Может обновлять только документацию и план.

### Kimi — реализация

- Читает `AGENTS.md`, Skill и раздел задачи по её ID.
- Проверяет актуальное состояние Git и кода; сверяет план с реальными
  классами/методами.
- Реализует только согласованный объём.
- Запускает доступные проверки.
- Обновляет статусы пунктов и результат проверки в плане.
- Обновляет Skill, если пользователь согласовал новое постоянное правило.
- **Не придумывает новые правила/архитектуру и не расширяет задачу.**

## 2. Как модели получают инструкции и доступ

- Оба этапа используют **тот же репозиторий** и те же `AGENTS.md`/Skill.
  Отдельные копии правил не создаются.
- Оператор выбирает модель в OpenCode. В текущей установке доступны Kimi-модели
  (подтверждено каталогом моделей): `opencode/kimi-k3`,
  `opencode/kimi-k2.7-code`, `opencode-go/kimi-k3.1-pro`,
  `opencode-go/kimi-k2.7-code`. Конкретную модель выбирает пользователь.
- Передача работы — через:
  1. план задачи в `docs/Development/IMPLEMENTATION_PLAN.md`;
  2. текущий Git-коммит/ветку/рабочую копию;
  3. `docs/SESSION-STATE.md` и `docs/HANDOFF.md` для состояния.
- Не полагайся на «предыдущий чат» как на единственный источник: если чего-то
  нет в файлах, это неизвестно.
- Если агенты работают в разных ветках/копиях, это должно быть явно указано в
  плане; не создавай ветки и не делай merge без разрешения.

## 3. Этап 1 — DeepSeek

1. **Пожелание:** сформулируй ожидаемый результат, ограничения и критерии
   готовности. Не пересказывай задачу в плане длиннее, чем нужно.
2. **Правила:** найди применимые разделы Skill. Отметь обязательные ограничения.
3. **Код:** проследи существующие классы, методы, вызовы, подписки, состояние,
   UI и данные. Не ограничивайся файлами из сообщения пользователя.
4. **Пробелы:** проверь историю и документацию; если правило не подтверждено,
   пометь `[O]`. Не выдумывай.
5. **Вопросы:** если неизвестность влияет на реализацию, задай вопрос через
   `question` с 2–4 вариантами.
6. **План:** добавь раздел `TASK-YYYY-NNN` в `IMPLEMENTATION_PLAN.md` по шаблону:
   цель, текущее состояние, чек-лист, последовательность, проверки, риски.
7. **Проверка плана:** каждый пункт должен быть выполним другим агентом;
   зависимости и ожидаемый результат должны быть явными.
8. **Стоп:** после анализа не переходи к коду.

## 4. Этап 2 — Kimi

1. **Подготовка:** прочитай `AGENTS.md`, Skill, нужный раздел плана.
2. **Git:** `git status`, `git log -1`, при необходимости `git diff`; не
   присваивай чужие незакоммиченные изменения.
3. **Актуальность:** сверь файлы/методы плана с кодом. Если код изменился:
   - план остаётся верным — продолжай;
   - появились новые зависимости — обнови план с причиной;
   - требования/архитектура неоднозначны — останови зависимую часть и спроси.
4. **Реализация:** выполняй пункты по порядку, минимальными изменениями, без
   необязательного рефакторинга и без несвязанных файлов.
5. **Проверки:** тесты, сборка/компиляция, smoke, `validate`,
   `translations check`, `git diff` — только доступные и подтверждённые.
6. **Статусы:** обнови каждый пункт:
   - `[x]` — реализовано и проверено;
   - `[!]` — блокер/вопрос с причиной;
   - `[-]` — отменено после согласованного изменения.
   Если код есть, а проверки не было — не ставь `[x]`; пиши
   «Реализация: выполнена. Проверка: не выполнена — причина».
7. **Skill:** если появилось постоянное правило — обнови существующий раздел,
   не создавай дубликат; временные решения в Skill не писать.
8. **Итог:** краткий отчёт: что сделано, файлы, проверки, незавершённое,
   вопросы, обновлялся ли Skill.

## 5. Защита от устаревших планов и конфликтов

- План — не безусловное разрешение на изменение кода.
- Перед каждым блоком проверяй актуальный файл и Git, а не только текст плана.
- Не перезаписывай разделы других задач; не удаляй невыполненные пункты.
- Если два плана затрагивают один класс/систему, проверь пересечение и
  зафиксируй порядок.
- Если план противоречит Skill/подтверждённому требованию — остановись,
  зафиксируй противоречие и задай вопрос.
- Не смешивай анализ, реализацию и приёмку в один непроверенный статус.

## 6. Границы

### Можно на этапе анализа

- читать код, конфиги, тесты, историю;
- создавать/обновлять план и только документацию;
- задавать вопросы.

### Нельзя на этапе анализа

- менять игровой код, сцены, префабы, ScriptableObject, YAML-контент и
  настройки;
- «попутно» исправлять найденные баги без отдельной задачи/плана;
- объявлять реализацию начатой.

### Можно на этапе реализации

- менять только файлы, перечисленные в плане (или обоснованно добавленные с
  обновлением плана);
- добавлять тесты для изменённой механики;
- обновлять план и Skill по правилам выше.

### Нельзя на этапе реализации

- менять несвязанные системы;
- переписывать архитектуру без решения пользователя;
- удалять чужую работу;
- выдавать непроверенный результат за проверенный;
- проходить геймплей за пользователя и называть это приёмкой.

## 7. Проверки и окружение

- Серверные тесты, `validate`, `translations check` — только `ssh home` /
  Docker, не локальный `dotnet`/Docker.
- Unity batch/EditMode/smoke — в копии проекта без `Library`; не открывать
  второй Unity с тем же проектом.
- Перед коммитом: `git diff --check`, просмотр `git diff`, проверка отсутствия
  несвязанных файлов.
- После блока: коммит/push, если пользователь не запретил.
- Геймплей вручную проверяет пользователь; агент фиксирует, что именно
  осталось на ручную проверку.

## 8. Исторические документы

`IMPLEMENTATION_CHECKLIST.md` и `DEVELOPMENT_CHECKLIST.md` — исторические
планы/решения. Новые задачи ведутся только в
`docs/Development/IMPLEMENTATION_PLAN.md`; не добавляй новые задачи в старые
чек-листы.