VanguardReMaster/AGENTS.md

11 KiB
Raw Blame History

Правила работы

Это общие правила для ассистента и будущих сессий. Детали проекта — в Skill vanguard-remaster; здесь только обязательный процесс.

Общение

  • Отвечай кратко, по существу и на русском, если не попросили другой язык.
  • Не пересказывай задачу, прочитанные файлы и очевидные действия.
  • Не пиши длинные вступления, заключения и отчёты по каждому шагу.
  • Сообщай только: изменённые файлы, результаты проверок, важные решения и блокеры.
  • Подробные объяснения давай по запросу или если без них можно сделать неверный вывод.

Контекст и Skill

  • Перед любой задачей по правилам, картам, способностям, ходам, состоянию матча, архитектуре, протоколу, клиенту или тестам загружай Skill vanguard-remaster.
  • В Skill есть отдельные документы:
    • game-rules.md — подтверждённые правила ККИ;
    • architecture.md — фактическая архитектура и границы систем;
    • card-implementation.md — реализация карт и эффектов;
    • workflow-and-decisions.md — соглашения, антипаттерны и открытые вопросы.
  • Перед началом работы читай docs/SESSION-STATE.md, затем docs/HANDOFF.md и docs/client-visual-direction.md; при работе с правилами — docs/game-rules.md, с картами — docs/ability-implementation.md.
  • Не пересказывай в ответе то, что уже сохранено в этих документах.

Никаких выдумок

  • Не выдумывай правила игры, карты, эффекты, API, классы, пути и пакеты.
  • Не считай правила других ККИ правилами этого проекта.
  • Не превращай предположение в договорённость. В Skill и документах явно разделяй: подтверждённое решение, фактическое устройство кода, предположение, открытый вопрос.
  • Перед реализацией изучай существующий код и найденные договорённости.
  • Если решение не определено и от него зависит реализация — сначала спроси.

Вопросы

  • Для существенной неопределённости используй специальный инструмент question (если он недоступен — задай вопрос обычным сообщением).
  • Предлагай 2–4 коротких варианта с рекомендацией и возможность своего ответа.
  • Дождись ответа, прежде чем принимать зависящее от него решение.
  • Не спрашивай о том, что уже однозначно установлено кодом, документацией или историей. Не прерывай работу ради мелочей.

Двухэтапная разработка

  • Любое пожелание, требующее изменения игры/кода, сначала проходит анализ и план DeepSeek, затем реализацию Kimi. Не начинай код без плана, кроме явно тривиальной правки, которую пользователь разрешил сделать сразу.
  • Активный план и журнал задач — docs/Development/IMPLEMENTATION_PLAN.md; подробный процесс — docs/Development/AGENT-WORKFLOW.md.
  • DeepSeek на этапе анализа не меняет игровой код, сцены, префабы, SO и конфиги; можно читать, задавать вопросы и обновлять план/документацию.
  • Kimi перед реализацией читает AGENTS.md, Skill и раздел задачи, проверяет Git и актуальность файлов/методов. Устаревший план не является разрешением на изменения.
  • Передача контекста — только через файлы репозитория и Git, не через память модели. Если агенты в разных ветках/копиях, это фиксируется в плане.
  • Статусы пунктов: [ ], [x], [!], [-]; отдельно указывается «Реализация» и «Проверка». [x] без проверки запрещён.
  • Kimi не расширяет объём, не делает необязательный рефакторинг и не удаляет чужие изменения. При новом существенном решении пользователя — вопрос и остановка зависимой части.

Изменения

  • Сначала найди существующую реализацию и связанные зависимости.
  • Делай минимальные изменения; не переписывай работающие системы без причины.
  • Не создавай дубликаты существующих классов, эффектов, оверлеев и сервисов.
  • Не меняй несвязанный код, сцены и префабы.
  • Сохраняй совместимость существующих механик и контрактов.
  • Учитывай побочные эффекты: пул карт, InputLockService, порядок событий, скрытую информацию и авторитет сервера.
  • Если ранее согласованное правило расходится с кодом, не выбирай молча: зафиксируй расхождение и задай вопрос.

Игровые проверки

  • Геймплей вручную проверяет пользователь. Не запускай тестовый бой и не объявляй игровую механику принятой по собственному прохождению.
  • Автоматические проверки правил, клиентские EditMode-тесты, validate, translations check и smoke-проверки запускать можно и нужно.
  • Не заявляй об успешной проверке, если она не запускалась. Указывай, что именно проверено, а что осталось на ручную проверку.

Окружение

  • Не запускай dotnet и Docker на рабочем ПК. Серверные тесты, validate и translations check — только на ssh home / Docker.
  • Не открывай второй экземпляр Unity с тем же проектом. Для batch-проверок делай копию проекта без Library.
  • Vanguard.Rules остаётся чистой библиотекой: без сети, БД, Orleans, Unity и файлового I/O.
  • Vanguard.Shared — только DTO/протоколы; netstandard2.1-сборка используется Unity. При изменении протокола пересобирай и заменяй client/Assets/Plugins/Vanguard.Shared/Vanguard.Shared.dll.
  • Клиент не является источником истины: состояние матча, RNG и скрытые данные остаются на сервере.

UI и взаимодействие

  • Выбор карты, круга, зоны или цели — клик/драг по объекту на поле, а не список кнопок в интерфейсе.
  • Кнопки — только глобальные действия и подтверждения: завершить ход, сдаться, отмена, принять/пропустить optional, подтвердить оплату.
  • Информационные оверлеи не перехватывают клики и не дублируют выбор кнопками.
  • Верхний CombatStats strip считается допустимым HUD; world-space Power/Shield — отложенный долг.
  • Для multi-target стоимости требуется отдельный CostPaymentOverlay; текущая панель «Действия» считается промежуточной реализацией, а не отменой требования.

Карты и способности

  • Каждая текстовая способность карты имеет ровно одну реализацию: CardScript (Abilities/Continuous/Activated), общий движок или флаг данных.
  • Не добавляй новую универсальную систему эффектов без подтверждённой необходимости.
  • После правок способностей проверяй весь реестр CardScripts.Default, тесты правил, validate и translations check.
  • Точные паттерны AUTO/ACT/CONT, стоимости, выборы целей и частые ошибки — в Skill card-implementation.md и docs/ability-implementation.md.

Проверки и завершение блока

После существенного блока:

  1. клиентские EditMode-тесты — в копии проекта;
  2. серверные тесты — на ssh home/Docker;
  3. validate и translations check;
  4. при клиентских изменениях — smoke и при необходимости standalone;
  5. коммит и push.

Состояние и следующие шаги — в docs/SESSION-STATE.md, подробная история — в docs/HANDOFF.md. Не дублируй одни и те же правила в нескольких местах: обновляй Skill, если пользователь согласовал новое долговременное правило.