mpakobecex
/
VanguardReMaster
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
VanguardReMaster/docs/Development/AGENT-WORKFLOW.md

11 KiB
Raw Blame History

Процесс: анализ → реализация (DeepSeek)

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

1. Роли

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

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

DeepSeek — реализация

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

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

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

3. Этап 1 — анализ

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

4. Этап 2 — реализация

  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; не добавляй новые задачи в старые чек-листы.