moonwell-editor/docs/ROADMAP.md

План полноценного MoonWell Editor

Дата: 2026-11-10. Статус: план разработки, не перечень готовых возможностей. Основание — принципы, текущее состояние, сценарии квестов, контракт релиза, установка и Play.

Цель — дать геймдизайнеру единую среду, в которой он создаёт и изменяет связанный контент WoW, проверяет его в игре и выпускает согласованное обновление клиента и сервера. Обязательное требование владельца: простое развёртывание на компьютере автора контента. Установка и тестовый сервер входят в продукт, а не остаются инструкцией для программиста.

1. Границы и определение готовности

Базовая цель этого плана — WoW Vanilla 1.12.1, build 5875, форк vMaNGOS владельца и закреплённая версия Benilla. «Все системы» означает все области авторинга контента этой целевой платформы и их взаимосвязи. Поддержка других дополнений — отдельные адаптеры и планы; системы Retail не считаются автоматически доступными в Vanilla.

Полноценная поддержка системы означает весь путь:

1. Найти существующий контент и понять его связи и ограничения.
2. Создать или изменить данные через понятный предметный интерфейс и превью.
3. Сохранить черновик, отменить/повторить действие, увидеть зависимые изменения.
4. Проверить ссылки, версии, условия, права владения и совместимость с сервером/клиентом.
5. Получить проверяемые артефакты и испытать результат в игре через Play.
6. Выпустить изменение, обновить его и безопасно вывести из использования.

Окно с полями таблицы, чтение DBC или успешная генерация SQL сами по себе не закрывают систему. Статусы в работе разделяются: «спроектировано», «реализовано», «проверено автоматически», «принято в игре», «выпущено». Наличие первых четырёх не доказывает пятый.

Редактор выпускает миграции world-БД, клиентские MPQ и серверные DBC; производные данные карт учитываются как serverMapData в существующем manifest. Исходная установка WoW используется только для чтения, результат собирается отдельно. Новая механика ядра или клиентская функция не становится возможностью редактора от появления соответствующего поля.

Для механик боссов сохраняется открытое решение владельца из PRINCIPLES. План учитывает их как обязательную границу полноты, но не выбирает язык, граф или серверный исполнитель. Аналогично новый исполнитель сценариев R2.5 — отдельная зависимость ядра. Обычный автор после его установки должен выпускать сценарии данными, без C++-скрипта для каждого квеста.

2. Отправная точка

Оценка выполнена по рабочей копии документации и структуре текущих модулей. Перечисленные в STATUS результаты прежних тестов не заменяют новый прогон и не объявляются проверками этого планирования. В checkout уже были незакоммиченные изменения квестов.

Область	Что есть	Что ещё не закрыто
Мир и NPC	Просмотр мира, размещение, перенос, поворот, Undo/Redo, модели и снаряжение, слой серверных спавнов	Игровая приёмка WMO, часть действий мышью, отдельные ошибки ресурсов; полноценный авторинг шаблонов NPC
Проект и SQL	JSON формата 2, чтение формата 1, диапазоны ID, baseline, журнал экспортов, проверки дрейфа и миграции	Общая модель зависимостей всех доменов, командное выделение ID, удаление опубликованного контента
Квесты	Собственные квесты, разговор/убийства/сбор, награды, цепочки, назначение квестодателя	Игровое прохождение, отдельные локализации, расширенные условия, сценарии, полный жизненный цикл
Play	Локальный отдельный клиент, точка старта, export/apply/restart, диагностика	Автоматическая подготовка окружения новичку; клиентские патчи и полный релиз; диагностика сценариев
Доставка редактора	Windows ZIP, стартовое окно, профиль пользователя, упаковка без игровых ассетов	Установщик, мастер проекта и тестового сервера, обновление приложения, поддержка чистой машины
Релизы контента	Схема manifest, проверка наследования, хешей и потребителей	Сборка/доставка DBC и MPQ, S3, проверка перед сборкой сервера, активация и восстановление
Остальные системы	Направления в прежнем R3–R9+	Предметные редакторы и сквозная приёмка ещё впереди

Ближайший предметный приоритет сохраняется: после цепочек — сценарии квестов R2.5. Завершение приёмки и развёртывание идут отдельными обязательными задачами готовности продукта.

3. Установка на компьютер автора — направление D

Пользовательский путь

1. Скачать один установщик Windows x64 и установить редактор. Portable ZIP остаётся альтернативой.
2. Выбрать существующую папку WoW. Мастер проверяет версию и нужные файлы и объясняет, что именно исправить, если проверка не прошла.
3. Выбрать «Подключить проект» или «Создать проект». Подключение выполняется по адресу проекта либо файлу подключения; локальная папка также поддерживается.
4. Нажать «Подготовить проверку в игре». Редактор получает совместимые готовые компоненты, готовит отдельное тестовое окружение и показывает ход загрузки и понятные ошибки.
5. Открыть мир, изменить контент и нажать Play. Дальнейшие запуски используют сохранённое окружение; его версии и состояние видны в одном месте.

Rust, Cargo, CMake, ручной SQL, терминал, назначение ID, копирование паролей и поиск prepare-play.ps1 не входят в обычный путь контент-мейкера. Настройку целевого ядра, диапазонов и канала релизов один раз выполняет владелец общего проекта. Для одиночной работы мастер создаёт изолированный тестовый проект с собственным пространством ID. Без сетевого доступа можно открыть локальный проект и доступные ресурсы; публикация и первичная загрузка отсутствующих компонентов требуют подключения.

D0 — проверить способ доставки тестового окружения

До обещания «одной кнопки» сделать небольшой установочный прототип на чистой Windows:

• Редактор и совместимый клиент поставляются готовыми сборками с закреплёнными версиями.
• Предпочтительный кандидат — управляемые локальные процессы готового vMaNGOS и совместимой БД, изолированные в профиле/каталоге окружения. Проверить наличие воспроизводимых сборок, совместимость схемы, импорт снимка данных, запуск мира и чистую остановку.
• Сравнить этот кандидат с управляемым окружением WSL2/контейнеров, уже близким к текущему локальному серверу. Выбрать основной вариант по результату прототипа, а не считать текущий PowerShell-скрипт готовой установкой для всех компьютеров.
• Если основной вариант требует WSL2, виртуализации, системного runtime, прав администратора или перезагрузки, мастер обнаруживает это заранее и сопровождает установку. Нельзя обещать отсутствие системных требований без проверки. Ручные команды не должны становиться обходным обязательным маршрутом.
• Зафиксировать решение, поддерживаемые версии ОС, объём загрузки/диска и сценарий обновления. Числа брать из замеров прототипа. Бюджет первого запуска установить после этих замеров.

Пока D0 не завершён, существующий Play с заранее подготовленным сервером остаётся режимом для разработчика, а простота установки не считается достигнутой.

D1 — мастер первого запуска

• Предварительные проверки: ОС, графический backend, runtime, место на диске, доступ к ресурсам и загрузкам, занятые порты, поддержка выбранного способа запуска сервера.
• Файл подключения проекта содержит идентичность, версии и адреса артефактов, но не общий пароль БД. Личные учётные данные запрашиваются отдельно и хранятся в системном хранилище секретов; переход от текущего settings.json проектируется как отдельная миграция.
• Тестовая world-БД создаётся из версионируемого базового снимка и миграций проекта. Реальные аккаунты и персонажи production не копируются. Тестовый аккаунт/персонаж подготавливаются мастером; доступность такого механизма должна быть проверена в D0.
• Папки программы, проектов, пользовательского профиля, кеша и тестового мира разделены. Репозиторий контента можно получить через мастер; знание команд Git не требуется.
• Логи собираются в отчёт диагностики без секретов. Ошибка содержит причину и действие: исправить путь, освободить порт, докачать файл, повторить шаг или восстановить окружение.

D2 — обновление и обслуживание

• Раздельные версии приложения, проекта, backend, клиента и релиза контента; проверяемая матрица совместимости. Обновление приложения не означает обновление игрового мира.
• Проверка целостности загрузок, доверенный канал и подпись установщика/обновлений, возобновление загрузки и установка подготовленного пакета без потери старой версии.
• Резервная копия перед миграцией проекта или локальной БД. Откат исполняемого файла не выдаётся за откат схемы данных: для несовместимых схем нужен совместимый снимок.
• Команды «Проверить окружение», «Восстановить компоненты», «Пересоздать тестовый мир»; последняя явно показывает, какие тестовые данные будут потеряны.
• Удаление программы сохраняет проекты. Очистка кеша, тестового сервера и личных настроек управляется отдельно; обновление не затрагивает исходную установку WoW.
• Авторские пакеты не содержат чужих игровых файлов. Клиентские ресурсы строятся из выбранной установки либо получаются из настроенного хранилища проекта по manifest.

Приёмка развёртывания

Человек, не участвовавший в разработке, на чистой поддерживаемой Windows без Rust, Git, настроенной БД и серверных исходников проходит путь «установка → проект → NPC → Play» без командной строки и правки конфигурационных файлов. Во время теста фиксируются время, размер загрузки, занятое место и все ручные действия. Любое обращение к разработчику для нормального первого запуска — незакрытая задача D1.

Повторить с путём на кириллице/с пробелами, обычным пользователем Windows, занятым портом, недоступной сетью, прерванной загрузкой, недостатком места и обновлением существующего профиля. Убедиться, что восстановление не стирает проекты и не запускает чужие службы.

D1 — условие первого релиза для внешнего автора; D2 — условие регулярного распространения. Windows x64 — первая поддерживаемая платформа; Linux/macOS требуют отдельных пакетов и приёмки, а не только успешной компиляции.

4. Матрица охвата систем

Обозначения результата: SQL — миграции world-БД; DBC — типизированные изменения клиентских/серверных таблиц; MPQ — клиентские ресурсы; карты — производные серверные данные. Это целевой охват, не утверждение, что каждый элемент уже поддержан текущим ядром. Точные таблицы, поля, форматы и доступные операции фиксируются по закреплённой ревизии перед реализацией каждого домена. Неподдерживаемая возможность получает явный статус.

Система	Что автор редактирует и видит	Результат и зависимости	Этап
NPC и существа	Шаблон и спавны, уровни/характеристики, фракция, реакции, флаги ролей, модели, снаряжение, возрождение	SQL; внешности также DBC/MPQ; разделение entry и конкретного спавна	R1, R4a
Группы и заселение мира	Группы, связи, пулы, вероятности появления, совместное возрождение, патч/событие	SQL; ссылки и проверка состава/ограничений	R5
Квесты	Тексты, цели разговора/убийства/сбора/исследования/события/применения, источники выдачи, награды, ограничения, повторяемость, цепочки и ветвления	SQL; условия, предметы, GO, сценарии; только реально поддержанные типы целей	R2, R2.5, R4, R9
Сценарии квестов	Актёры, точки, движение, реплики/эмоции, волны, ожидания, исходы и очистка	SQL после подтверждённого исполнителя сессий; runtime не хранится в проекте	R2.5
Диалоги и взаимодействия	Gossip, тексты, варианты, условия, услуги и переходы, локализации	SQL; общий редактор условий и проверка достижимости вариантов	R4b
GameObject	Шаблоны/спавны, двери, сундуки, кнопки, ловушки, ресурсы, квестовые объекты	SQL, внешности DBC/MPQ; формы по типу объекта, связи с добычей/квестами	R4b
Предметы	Тип, качество, статы, требования, уникальность, привязка, прочность, заряды, сумки, комплекты, визуальный вид	SQL + при необходимости DBC/MPQ; заклинания/локализация	R4a, R9a
Добыча	Добыча существ, объектов, предметов, рыбалка, снятие шкур, карманная кража, распыление; группы и ссылки	SQL; проверка вероятностей, рекурсии, достижимости и патча	R4a, R9b
Торговля и услуги NPC	Ассортимент, цены, ограниченные запасы, пополнение, ремонт, банк/почта/трактир/аукцион как роли и точки доступа	SQL; доступные параметры текущего ядра, без редактора состояния игроков	R4b
Обучение	Тренеры, доступные заклинания/навыки, стоимость, раса/класс/уровень/предпосылки	SQL + DBC при изменении самих навыков	R4b, R9b
Маршруты и обычный AI	Точки, паузы, скорость/режим движения, реакции, вызовы, способности в рамках поддержанного AI	SQL; видимость навигации и ограничения backend; отдельно от механик боссов	R5
Условия и зависимости	Класс, раса, фракция, уровень, квест, предмет, навык, репутация, событие, состояние мира; композиция в пределах backend	SQL/DBC по потребителю; общий язык условий и проверка несовместимых комбинаций	R3a и далее
Такси	Узлы, NPC, маршрут и высота пути, стоимость/доступность, предпросмотр полёта	DBC/MPQ + SQL; согласование клиентского и серверного пути	R6
Транспорт и переходы	Корабли/дирижабли/подвижные объекты, остановки, время, посадка, межкартовые переходы, порталы и телепорты	SQL/DBC/MPQ; проверка поддержки каждого типа, серверной траектории и коллизий	R6.2, R8
Ландшафт и размещение ресурсов	Высоты, текстуры/слои, отверстия, вода, область карты, M2/WMO/doodad, трансформации	ADT/WMO и другие штатные форматы в MPQ; пересборка затронутых серверных карт	R7
Атмосфера мира	Освещение, туман, skybox, вода/жидкости, музыка, звуки, погода и зональные настройки	DBC/MPQ/SQL по системе; сверка отображения и влияния на игру	R7, R9d
Новые карты и зоны	Карта, тайлы, области/подобласти, границы, миникарта/карта мира, входы/выходы, исследование	DBC/MPQ/карты/SQL; единый пакет и проверка достижимости	R8
Пространственные правила	Area trigger, безопасные точки, кладбища, возвращение к телу, вода, коллизии, LOS и навигация	SQL/DBC/карты; валидация высоты/этажа и путей	R7, R8
Подземелья и рейды	Вход, привязки, сброс, группы мобов, патрули, двери, объекты, добыча и допустимые параметры инстанса	SQL/DBC/MPQ/карты; поддержка состояния инстанса проверяется отдельно	R8
Механики боссов	Фазы, таймеры способностей, реакция на события, состояние encounters	Способ авторинга/исполнения не выбран; не закрывается общим AI автоматически	Решение владельца
Заклинания и ауры	Параметры поддержанных эффектов, стоимость, время, дальность, цели, цепочки рангов, proc/ограничения, визуальные эффекты	DBC + серверные SQL-данные + MPQ; семантика и пределы ядра	R9a
Классы, таланты, навыки	Деревья, ранги, предпосылки, стартовые/обучаемые умения, параметры прогрессии	DBC/SQL; новые классы/эффекты требуют отдельной проверки клиента и ядра	R9a
Питомцы и спутники	Семейства, способности/обучение, доступные данные приручения/призыва, модели	DBC/SQL/MPQ; не редактирование текущего питомца игрока	R9a
Профессии	Рецепты, реагенты, инструменты, результаты, требования навыка, обучение, ресурсные узлы	SQL/DBC; предметы, добыча, GO, заклинания, тренеры	R9b
Фракции и репутация	Отношения, стартовая репутация, награды/штрафы, ограничения/доступность контента	DBC/SQL; общие условия и проверка взаимосвязей	R9c
Персонаж и стартовый опыт	Стартовые зоны, позиции, предметы, умения, доступные параметры рас/классов и внешности	SQL/DBC/MPQ; новые расы/слоты/механики за границей обычного контента	R9c
Мировые события	Расписание, включение спавнов/торговцев/квестов, праздники, состояния мира и зависимости	SQL/DBC; часовой пояс, пересечения, включение/выключение и очистка	R9d
PvP	Поля боя: карты, входы, команды, стартовые точки, кладбища, объекты, доступные награды/правила	SQL/DBC/карты; новые режимы/алгоритмы матчей — зависимость ядра	R9e
Ресурсы и локализации	Поиск/превью моделей, текстур, иконок, звука, эффектов; импорт совместимых файлов; языковые версии текстов	MPQ/DBC/SQL; происхождение, хеши, форматы, fallback и полнота переводов	R3b и все домены
Баланс и аудит	Связи «источник → стоимость → награда», доступность предметов/квестов, массовые изменения и отчёты	Проверки и пакеты изменений; оценка не заменяет тест геймплея	R4 и далее

Аккаунты, бан-листы, гильдии, аукционные лоты, почтовые ящики и инвентари живых персонажей относятся к администрированию/runtime. Редактор учитывает связанные точки доступа и контентные настройки, но не становится панелью изменения персональных данных игроков. Игровые интерфейсы, QoL, сетевой протокол, новые боевые формулы и новые типы эффектов относятся к клиенту/ядру; для них нужен отдельный контракт совместимости.

5. Общая архитектура

Один проект и связанные предметные редакторы

Сохранить текущие границы: editor-project — модель и команды; editor-vmangos — адаптер схемы/чтение/экспорт; editor-release — контракт выпуска; editor-app — представление; editor-config — личная конфигурация; CLI использует ту же логику, что окно. Новые модули выделять по ответственности и размеру, без переписывания работающего ядра редактора ради абстрактной универсальности.

Рабочие пространства интерфейса: «Мир», «Контент», «Сценарии», «Ресурсы», «Изменения», «Проверка в игре», «Релизы». Они используют общий поиск, выделение и инспектор. Из квеста можно перейти к NPC, предмету, его источнику добычи и месту в мире, сохраняя контекст. Сырые ID, таблицы и биты доступны в диагностике, а обычная форма показывает названия, смысл и превью. Множественный выбор, фильтры слоёв, копирование и пакетное редактирование добавляются к предметным операциям с общим Undo/Redo.

Обязательные общие службы

Служба	Контракт
Целевая платформа	Закреплённые версии движка/ядра/клиента/схемы/контентного патча; явная проверка поддерживаемых операций, одинаковый патч каталога, превью и экспорта
Идентичность	Стабильные внутренние ссылки; раздельные пространства entry/guid/DBC ID; резервирование между проектами/ветками, запрет коллизий и опасного повторного использования
Владение	У каждой записи происхождение: базовая, собственная, явно переопределённая. Просмотр чужих данных не даёт права их перезаписать
Зависимости	Индекс прямых/обратных ссылок, «где используется», замыкание пакета, проверка удаления и циклов там, где цикл недопустим
Команды редактирования	Save/Undo/Redo охватывают все связанные сущности одной операции; восстановление черновика после сбоя; миграции формата проекта без потери неизвестных данных
Условия	Предметная модель доступности с явной компиляцией в возможности конкретного потребителя; объяснение, почему контент недоступен
Тексты	Стабильные ключи, базовый язык, локали, подстановки и fallback; единая модель для квестов, предметов, диалогов и сцен
Проверки	Быстрые локальные, межсущностные, серверные и проверки артефактов; ошибка ведёт к объекту/полю/точке в мире
Ресурсы	Реестр путей/хешей/источников, превью, зависимости и кеш; тяжёлые операции выполняются фоном с отменой
Диагностика	Версии, причины отказа, ссылки на журнал; для Play — результат подготовки и загрузки, для сценариев — запуск/шаг/актёры/события

Общий слой формируется первым работающим примером и расширяется вместе с доменами. Не нужно сначала описывать все таблицы WoW, чтобы завершить квест или создать предмет. Но каждый новый домен обязан подключиться к этим контрактам.

Сборка и выпуск

Путь: проект → проверки → план изменений → сборка → изолированный Play → кандидат релиза → публикация → активация → контроль результата.

• Сборка детерминирована; изменения ресурса пересобирают его зависимые DBC/MPQ/карты.
• Manifest содержит полный набор бинарных артефактов и точные хеши; SQL остаётся в истории контента. Сначала загрузка неизменяемых объектов, затем публикация manifest.
• Сервер получает нужные DBC до компиляции; отсутствующий/повреждённый файл блокирует сборку. Клиент получает согласованный пакет через собственный launcher manifest.
• Активация согласует версии SQL, DBC, MPQ и карт. Несовместимые частичные наборы не допускаются к запуску. Необходимость перезапуска и очистки WDB показывается автору заранее.
• MyISAM не даёт транзакционного отката: проверки до первой записи обязательны, но не защищают от аварии во время записи. Нужны режим применения без конкурирующих изменений, резервная копия, журнал шагов, обнаружение частичного применения и проверенный путь восстановления. Переключение manifest назад само по себе не откатывает SQL.
• Удаление опубликованной сущности начинается с поиска ссылок, оценки влияния на прогресс игроков и вывода из доступности. Физическое удаление разрешается отдельной проверяемой миграцией; Undo в редакторе не отменяет уже применённый релиз.
• Git хранит проекты, описание релиза и миграции. DBC, MPQ, игровые ресурсы и производные карты в Git не попадают. Личные секреты не входят в пакет проекта или диагностику.

6. Этапы и результаты

Номера R0–R8 сохраняют связь со старым планом. R9+ разбит на конкретные этапы. Это порядок зависимостей, не обещание сроков. D и общие средства проходят через весь план.

Этап	Содержание	Условие завершения
G0 — закрыть известные пробелы	Приёмка NPC на земле/WMO, ввод/Undo/диалоги, предметные квесты и цепочки; разобрать ошибки камеры/ресурсов	Чек-лист с доказательствами, оставшиеся ограничения явно воспроизводимы; исторические тесты не подменяют игровую приёмку
D0 → D1	Прототип готового тестового окружения, установщик и мастер первого запуска	Независимый автор на чистой Windows ставит NPC и запускает Play без терминала
R2.5a	Серверный прототип независимых сессий сценария	Два запуска рядом и группа из двух игроков не смешивают актёров, шаги и зачёт; проверены отмена/очистка/перезапуск
R2.5b	Модель сценария, версия backend, валидация, миграции	Отсутствующий backend блокирует экспорт; сохранение/повтор/изменение работают с baseline, все ссылки проверены
R2.5c	Точки и актёры в мире, список шагов/веток, реплики, волны, диагностика Play	Вручную пройден сценарий от принятия до награды и следующего квеста, включая негативные случаи контракта
R3a	Общие ссылки/ID/владение, возможности backend, согласованный патч, основа локализаций и условий	Два связанных домена используют общий контракт; ошибки ведут к сущности, чужая ссылка/коллизия блокирует запись
R3b	DBC reader/writer с проверкой обратного чтения, MPQ-сборка, каталог ресурсов, S3 и manifest, server build gate	Один малый релиз меняет SQL и DBC/клиентский ресурс, полностью доходит до чистого клиента и сервера; повреждённый артефакт блокирует запуск/сборку
R4a	Полноценные шаблоны NPC, предметы и добыча	Автор создаёт предмет, назначает источник, использует его в квесте и получает/сдаёт в игре
R4b	GameObject, gossip, услуги, торговцы и тренеры; расширение квестовых источников/условий	Рабочий лагерь с диалогами, торговлей, объектом и квестом выпускается одним согласованным пакетом
R5	Постоянные патрули, группы/пулы, обычный AI и связи с событиями	Патруль проходит точки, корректно реагирует на бой/сброс и возвращается; редактор показывает проблемы навигации
R6.1	Полётная сеть	Создан и пройден маршрут такси; доступность, стоимость и путь согласованы между клиентом и сервером
R6.2	Транспорт и его переходы	Посадка, движение, остановка, выход и переход карты проверены; конкретные поддержанные типы перечислены
R7	Правка существующей карты, окружение, ресурсы, сборка производных карт	Изменён участок, проверены отображение, коллизии, LOS и навигация; локальная пересборка даёт согласованный пакет
R8	Новые карты/зоны, входы, кладбища, подземелья и рейды без новых механик боссов	Новая небольшая зона и инстанс доступны в игре; работают вход/выход, смерть/возврат, объекты, добыча и поддержанный сброс
R9a	Заклинания/ауры, таланты, классовые навыки и питомцы в пределах backend	Связанный набор способности/таланта/обучения проходит проверку клиента и серверной семантики
R9b	Профессии и полный цикл ресурсов	Ресурс → добыча → реагент → рецепт → обучение → созданный предмет реально проходится
R9c	Репутация, фракции, стартовый опыт и параметры прогрессии	Изменение репутации/условия открывает нужный контент; новый тестовый персонаж получает правильные стартовые данные
R9d	Мировые события, расписания, состояния мира, оставшиеся параметры окружения	Событие включается/выключается и переживает перезапуск без лишних спавнов/связей; проверены пересечения
R9e	PvP-контент поддержанных режимов	Ручной сценарий входа, старта, смерти/возрождения, результата и награды на тестовом поле боя
R9f	Аудит полноты, массовое редактирование, командная работа, большие проекты, D2	По матрице нет забытых областей: каждая принята либо явно ограничена; обновление/восстановление/доставка проверены

Транспорт перенесён из неопределённого R9+ к такси как предложение по зависимости общих инструментов путей. Это не означает, что транспорт и такси имеют один формат данных. Локализации и командная сохранность начинаются в общем слое и завершаются в каждом домене; откладывать их полностью до R9f нельзя.

Если серверный прототип R2.5 требует отдельного решения/изменения ядра, зависимая часть сценариев ждёт это решение. Независимые D0/D1, приёмка и R3 продолжаются. Неработающий интерфейс сценариев не считается обходом блокировки backend.

6.1. Модели и автоматический выбор исполнителя

Правило владельца от 2026-11-10: агенты самостоятельно выбирают модель для этапа и передают ей задачу без повторного запроса разрешения. Координатор руководствуется таблицами ниже. Это политика проекта, а не сравнительный benchmark на его исходниках.

Механизм: действующий чат не меняет модель от записи в Markdown. Координатор запускает подагента с указанными моделью и effort; основной чат остаётся координатором. Если текущая модель/effort достоверно совпадают, дополнительный подагент не нужен. При смене этапа назначение проверяется заново. Полная процедура закреплена в AGENTS.md.

Профиль проекта	Модель	Reasoning effort	Назначение
mw_sol_high	gpt-6.1-sol	high	Основная реализация, отладка и интеграция
mw_astra_high	gpt-6-astra	high	Архитектура, опасные изменения данных и межсистемная семантика
mw_astra_xhigh	gpt-6-astra	xhigh	Конкурентные сессии и особо сложные дефекты
mw_terra_high	gpt-6.1-terra	high	Проверка экрана, интерфейса и первого запуска через доступные UI-инструменты
mw_luna_high	gpt-6-luna	high	Ограниченные правки документации и механические проверки

Файлы этих профилей: .codex/agents/. Настройки проекта включают подагентов в .codex/config.toml. Они не изменяют модель основного чата, права среды или пользовательские настройки. Если среда предоставляет только запуск с явными параметрами, используются значения из профиля, без обращения к имени профиля.

Этап / сценарий работы	Основной исполнитель	Разделение и повышение сложности
G0 — приёмка и текущие дефекты R0/R1/R2	mw_sol_high	UI-проверка — mw_terra_high; сложная геометрия/камера/WMO — mw_astra_high
D0 — выбор и прототип способа развёртывания	mw_astra_high	Сравнение вариантов, ограничения Windows, сервер/БД и восстановление
D1 — установщик и мастер запуска	mw_sol_high	Сценарий первого запуска на чистой машине — mw_terra_high
D2 — обновление и восстановление	mw_astra_high	После фиксации контракта отдельные компоненты реализует mw_sol_high
R2.5a — независимые серверные сессии	mw_astra_xhigh	Изоляция, повторные события, участники, зачёт, очистка и перезапуск
R2.5b — модель сценариев и миграции	mw_astra_high	Версия backend, baseline, жизненный цикл данных и отказы
R2.5c — визуальный редактор сценариев	mw_sol_high	Проверка интерфейса — mw_terra_high; изменение серверного контракта возвращается в R2.5a/b
R3a — ссылки, ID, владение, условия	mw_astra_high	Общая модель и совместимость всех доменов
R3b — DBC/MPQ, сборка и выпуск	mw_astra_high	Ограниченные инструменты по готовой спецификации — mw_sol_high
R4a — NPC, предметы и добыча	mw_sol_high	Новая схема миграций или изменение гарантий данных — mw_astra_high
R4b — GO, диалоги, торговцы и услуги	mw_sol_high	Межсистемные ограничения и опасное удаление — mw_astra_high
R5 — патрули, группы и обычный AI	mw_astra_high	После определения поведения формы UI реализует mw_sol_high
R6.1 — полётная сеть	mw_sol_high	Неизученный формат/серверная семантика — mw_astra_high
R6.2 — транспорт и переходы карт	mw_astra_high	Системы координат, посадка и согласование траекторий
R7 — правка карты и производные данные	mw_astra_high	Сложный дефект геометрии/коллизий/навигации — mw_astra_xhigh
R8 — новые карты и инстансы	mw_astra_high	Жизненный цикл инстанса и согласованность артефактов
R9a — заклинания, таланты и питомцы	mw_astra_high	Семантика эффектов и ограничения ядра/клиента
R9b — профессии и ресурсы	mw_sol_high	Новая серверная механика не маскируется под обычный авторинг
R9c — репутация и стартовый опыт	mw_sol_high	Неочевидные взаимодействия условий/прогрессии — mw_astra_high
R9d — события и состояния мира	mw_astra_high	Пересечения, перезапуск, включение и очистка
R9e — PvP-контент	mw_astra_high	Команды, состояния матча, результат, возрождение и награды
R9f — итоговый аудит и командная работа	mw_astra_high	Найденные ограниченные дефекты исправляет mw_sol_high; D2 следует своей строке

Сквозные задачи выбираются по характеру конкретного поручения. Простая правка документации в R7 не требует модели для геометрии, а изменение SQL в R4 не становится безопасным от того, что находится рядом с формой интерфейса.

Сквозной сценарий	Исполнитель
Уточнение архитектуры, контрактов и зависимостей плана	mw_astra_high
Обычная разработка Rust, локальная отладка, интеграция по согласованному контракту	mw_sol_high
Исправление документированной опечатки, синхронизация ссылок/таблиц, механическая проверка конфигурации	mw_luna_high
Проверка удобства UI, расположения элементов, мастера установки и сообщений об ошибках	mw_terra_high
Анализ SQL-миграций, потери данных, совместимости форматов, публикации и восстановления	mw_astra_high
Конкурентность, двойной зачёт, смешение сессий; неразрешённая сложная геометрия	mw_astra_xhigh
Независимое ревью обычного изменения кода	mw_sol_high, отдельное поручение с требованием и diff
Независимое ревью изменений данных, серверных сессий и релизов	mw_astra_high; конкурентные сессии — mw_astra_xhigh
Ручное игровое прохождение, боевые проверки	Человек; подготовка и анализ — модель соответствующего этапа
Механики боссов и новые возможности вне текущих принципов	Сначала решение владельца; после разрешения проектирование — mw_astra_high

Правила повышения сложности и передачи:

1. Координатор кратко сообщает этап, профиль и границы поручения. Передача содержит исходное требование, нужные пути/документы, предыдущие выводы и критерии приёмки.
2. Назначенный исполнитель не запускает другого агента только ради повторения этой политики. Он выполняет поручение либо возвращает конкретную потребность в повышении.
3. При выявлении риска для данных/версий/серверного состояния сразу перейти к профильной строке. После двух неуспешных попыток с проверенными гипотезами Sol/Luna/Terra передают проблему Astra High; не повторять одинаковый запуск без новых данных.
4. Astra High переходит на Extra High при подтверждённой сложной проблеме конкурентности или геометрии, которую текущий анализ не разрешил. Max/Ultra автоматически не включать.
5. После решения сложной части обычную реализацию можно вернуть Sol с зафиксированным контрактом. Один набор файлов не изменяется двумя исполнителями одновременно.
6. При отсутствии выбранной модели использовать доступный подходящий вариант, явно указав отклонение. Если недоступны все подагенты — работать текущей моделью и сообщить об ограничении. Нельзя объявлять недоступное переключение успешным или скрывать невыполненные проверки. Ограничения разрешений и продуктовые решения сохраняются.
7. В отчёте различать запрошенный профиль, принятый инструментом запуск и подтверждённую средой модель. Самоназвание модели в её ответе не является проверкой маршрутизации.

Механизм опирается на официальную документацию подагентов Codex. Профили фиксируют обе настройки; доступность моделей и загрузка проектных профилей зависят от клиента. Таблица сама по себе не является программным диспетчером: выбор выполняет координатор по обязательной инструкции AGENTS.md через инструменты среды.

7. Сквозная приёмка продукта

Для каждого домена проверяются модель и ссылки, миграции/бинарные форматы, интерфейс и реальное поведение в клиенте. SQL-тесты используют временные таблицы с явным DDL и контролем неизменности постоянных данных. Проверка серверного кода не заменяется симуляцией в редакторе. Бои и прохождение игровых сценариев выполняются человеком.

Для изменений Rust перед коммитом обязательны отдельные успешные результаты cargo fmt --all, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace. Для форматов нужны обратное чтение и сравнение результата; для публикации — отказ на несовместимость, обрыв загрузки/применения и восстановление. Созданные для проверок сборки удаляются после завершения; release-файлы и отчёты сохраняются.

Основной демонстрационный проект растёт вместе с редактором:

1. Лагерь: новый автор устанавливает редактор, ставит NPC, создаёт цепочку и проходит её.
2. Живой лагерь: сценарий сопровождения, диалоги, торговец, предмет, добыча, ресурс и патруль.
3. Новая территория: изменённый ландшафт, зона, такси/транспорт, кладбище и подземелье.
4. Связанный мир: профессия, способность/талант, репутация, событие и PvP-контент.
5. Выпуск командой: второй автор получает проект на чистой машине; конфликт правок обнаруживается, пакет воспроизводится, клиент и сервер обновляются, восстановление проверено.

Каждая демонстрация проходит через общий путь проекта и релиза. Ручная правка SQL/DBC после экспорта, необходимая для нормальной работы примера, означает незавершённую функцию.

Для производительности сначала зафиксировать оборудование и реальные малый/средний/большой проекты. Измерять время открытия, отзывчивость ввода, кадр, память/GPU, загрузку каталога, сохранение, Check, сборку и подготовку Play. Согласовать бюджеты по базовым замерам; не объявлять произвольные FPS или размеры мира уже подтверждёнными требованиями.

8. Ближайшие задачи

Порядок	Задача	Проверяемый результат
1	Свести незакрытую приёмку R1/R2 в сценарии проверки	Отчёт по WMO, вводу, предметным квестам/цепочке; ошибки отделены от непроведённых проверок
2	D0: чистая машина и прототип поставляемого локального мира	Решение о runtime, реальные системные требования, запуск готового сервера/клиента без сборки исходников
3	R2.5a: спецификация возможностей и проверка сессий	Результат двух независимых запусков, группы и постороннего; перечень необходимых изменений ядра
4	D1: мастер подключения проекта и окружения	Новый пользователь проходит установку до Play; ошибки устраняются через интерфейс
5	R2.5b после готовности backend	Версионируемая модель, baseline, миграции и отказ на несовместимый исполнитель
6	R2.5c	Визуальный сценарий и ручная сквозная приёмка; ни одной волны/таймера после очистки
7	Инвентаризация целевой схемы	Реестр таблиц/DBC/ресурсов по матрице: чтение/создание/изменение/удаление, ссылки, версия, ограничения
8	R3a на существующих NPC/квестах и первом новом домене	Общие ссылки/ID/локализации/условия без регрессии нынешнего рабочего цикла
9	R3b на одном небольшом клиентско-серверном изменении	Проверяемый релиз от проекта до чистого окружения и доказанный отказ на повреждение
10	R4a: предмет → добыча → квест	Первый законченный новый домен, использующий общий фундамент

Каждую строку разбивать на небольшие задачи с входными данными, изменяемыми модулями, артефактом результата, критериями приёмки и зависимостью. Следующий этап оценивается после прототипа самого рискованного места. Календарь до проверки backend сценариев, D0 и записи форматов был бы недостоверным; сроки назначаются на ближайший проверенный объём.

9. Решения, которые план не принимает за владельца

Решение	Когда необходимо	Что можно делать до него
Способ программирования механик боссов	До реализации их редактора/исполнителя	Карты, инстансы и остальной контент в рамках принципов
Изменение ядра для изолированных сценариев	После R2.5a, если штатных возможностей недостаточно	Спецификация/прототип, развёртывание, приёмка и общий выпуск
Правила изменения чужого upstream-контента	Перед универсальным импортом с правкой существующих записей	Чтение, новые собственные сущности; уже разрешённое назначение квестодателей сохраняется
Диапазоны ID, каналы релиза, роли выпуска	Перед подключением команды и production	Изолированное тестовое пространство и прототип мастера
Новые расы/классы/эффекты и системы вне Vanilla	Перед расширением клиентского/серверного контракта	Редактирование данных уже поддержанных систем

Эти решения не мешают составить и выполнять независимые части плана. Наличие строки в матрице не является разрешением менять соседний Benilla, публиковать production-релиз или коммитить в рабочий репозиторий ядра.

10. Основания и сопровождение плана

• PRINCIPLES.md задаёт границы авторинга и выходные артефакты.
• STATUS.md хранит фактическое состояние и доказательства проверок; этот план хранит целевой охват и зависимости. После шага обновляются статус и соответствующая строка плана.
• quest-scenarios.md — подробный контракт R2.5, включая конкурентные запуски, реальные события, очистку и отличие изоляции состояния от визуального phasing.
• release-manifest.md — действующий контракт артефактов; его расширение требует версии схемы и миграции потребителей, а не добавления неизвестных полей в schema 1.
• install.md и play.md описывают сегодняшнюю установку и проверку; мастер и автоматическая подготовка из направления D пока запланированы.
• Upstream vMaNGOS подтверждает ориентацию на прогрессию Vanilla и разделение контента и ядра. Конкретные возможности форка определяются его закреплённой ревизией, а не текущим README upstream.

Матрица — исходный реестр охвата. До заявления «поддержаны все системы» её нужно сверить с полной инвентаризацией целевой схемы БД, DBC, форматов и серверных обработчиков. Неизученное не считается ни поддержанным, ни ненужным: оно получает отдельный пункт и проверку.