Документы описывают целевую архитектуру. Реализованное состояние рендера зафиксировано отдельно в ../RENDER.md. Если описание целевого решения расходится с кодом, это считается известным архитектурным долгом, а не разрешением обходить границы слоёв.

Нормативные слова ДОЛЖЕН, НЕ ДОЛЖЕН, СЛЕДУЕТ и МОЖЕТ задают обязательность решения. Существенные отклонения оформляются Architecture Decision Record (ADR).

Карта документов

Документ	Назначение
ARCHITECTURE.md	Границы модулей, направления зависимостей, runtime и editor
CLIENT_FEATURES.md	Полная карта функций клиента WoW 3.3.5a
GODOT_EDITOR.md	Архитектура инструментов внутри Godot Editor
CONTENT_AND_SERVER_DATA.md	Content Project, данные клиента, БД TrinityCore/AzerothCore, сборка и публикация
GAME_DESIGN.md	Принципы геймдизайна, квестов, локаций, подземелий и баланса
TESTING.md	Стратегия тестирования runtime, протокола, рендера и authoring pipeline
ROADMAP.md	Последовательность вертикальных срезов и критерии готовности
REFERENCES.md	Использованные локальные reference-проекты и правила работы с ними

Обязательный workflow изменения функции

Найти функцию в матрице CLIENT_FEATURES.md.
Определить владельца данных и границу модуля по ARCHITECTURE.md.
Для контента описать канонические данные и server adapter по CONTENT_AND_SERVER_DATA.md.
Для игровых изменений сформулировать player goal, feedback и failure states по GAME_DESIGN.md.
До реализации определить тесты и observability по TESTING.md.
Выполнить работу вертикальным срезом и обновить статус feature matrix.

Definition of Done для документации

Изменение считается документированным, если указаны:

владелец состояния;
публичные команды, события или read models;
формат сохранения и версия схемы, если есть данные;
серверная авторитетность и поведение при рассинхронизации;
пользовательский сценарий и обработка ошибок;
автоматические и ручные проверки;
migration/rollback для изменяемого формата или БД.