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

Это общие правила для ассистента и будущих сессий. Детали проекта — в 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 коротких варианта с рекомендацией и возможность своего ответа.
- Дождись ответа, прежде чем принимать зависящее от него решение.
- Не спрашивай о том, что уже однозначно установлено кодом, документацией или
  историей. Не прерывай работу ради мелочей.

## Изменения

- Сначала найди существующую реализацию и связанные зависимости.
- Делай минимальные изменения; не переписывай работающие системы без причины.
- Не создавай дубликаты существующих классов, эффектов, оверлеев и сервисов.
- Не меняй несвязанный код, сцены и префабы.
- Сохраняй совместимость существующих механик и контрактов.
- Учитывай побочные эффекты: пул карт, `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, если пользователь согласовал новое долговременное правило.