149 lines
10 KiB
Markdown
149 lines
10 KiB
Markdown
# Процесс 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`; не добавляй новые задачи в старые
|
||
чек-листы.
|