10 KiB

Raw Blame History

Процесс 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

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

4. Этап 2 — Kimi

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

10 KiB Raw Blame History Unescape Escape