moonwell-editor/AGENTS.md

Правила для агента

Перед работой прочитай:

1. docs/PRINCIPLES.md — основные принципы: что такое редактор, что в нём делается и куда уходит результат. При противоречии с планом главнее принципы.
2. docs/STATUS.md — что сделано, что не проверено и что делать дальше. Обнови этот файл, когда закончишь шаг.
3. docs/ROADMAP.md — обязательная таблица моделей и правила автоматической передачи задач.

Автоматический выбор модели

Владелец разрешил и требует автоматически выбирать модель по этапу и типу работы. Не спрашивай разрешение на каждую передачу задачи. Перед существенной работой найди строку в разделе 6.1 ROADMAP и выбери указанные модель и reasoning effort. Если этап не определён, применяй таблицу сквозных задач; по умолчанию — gpt-6.1-sol, high.

• Если текущая модель и effort достоверно совпадают с назначением, выполняй задачу сам. Иначе делегируй её через доступный инструмент подагентов с явными моделью и effort. Не считай, что текстовая инструкция меняет модель уже запущенного чата.
• Профили проекта находятся в .codex/agents/. Если инструмент не поддерживает имена профилей, передавай их model и model_reasoning_effort явными параметрами запуска. Для collaboration.spawn_agent это model, reasoning_effort, fork_turns="none"; полное наследование истории в этом инструменте не допускает переопределения модели.
• Передай исполнителю цель, этап, границы разрешённых изменений, файлы, текущее состояние, критерии готовности, проверки и обязательные документы. Укажи выбранную модель/effort как параметры назначения, не проси модель угадывать собственную идентичность.
• Назначенный исполнитель не повторяет маршрутизацию и не создаёт цепочку таких же подагентов. При необходимости более сильной модели возвращает координатору конкретную причину и результаты. Координатор выбирает следующего исполнителя по ROADMAP.
• Один файл одновременно изменяет один исполнитель. Зависимые этапы выполняются последовательно; независимые задачи можно делегировать параллельно в пределах лимитов среды. Координатор проверяет результат и завершает общую задачу.
• Если модель или механизм подагентов недоступны, явно сообщи ограничение и выбранный доступный вариант, продолжи допустимую работу. Не утверждай, что переключение состоялось, не обходи ограничения среды и не меняй глобальные настройки пользователя.
• Telegram-уведомление отправляет только координатор после завершения общей задачи, не каждый подагент. Выбор модели не меняет разрешения на БД, коммиты и публикацию.

Сборка и проверки

cargo fmt --all
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

Перед коммитом все три команды должны пройти. Проверяй результат каждой: &&-цепочка с grep проглатывает код выхода.

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

Окно можно проверить по логу и снимку кадра. Переменные окружения:

Переменная	Что делает
EDITOR_SHOT=<png>	Сохраняет кадр и закрывает окно. Перед этим пишет в лог строку EDITOR_SHOT … с положением камеры, точкой под центром экрана и состоянием превью.
EDITOR_SHOT_AT=<сек>	Когда снимать (по умолчанию 25; миру нужно время подгрузиться).
EDITOR_SHOT_DIST=<ярды>	Расстояние камеры до точки --at под 45° (по умолчанию 25).
EDITOR_SHOT_VIEW=x,y,z;tx,ty,tz	Фиксированное положение камеры и точка взгляда в координатах WoW для воспроизведения кадра. При EDITOR_SHOT пользовательский ввод не двигает диагностическую камеру.
EDITOR_SHOT_SWEEP=1	Плавное вращение диагностической камеры вокруг точки взгляда для проверки согласованности геометрии.
EDITOR_PROBES=x,y,z;…	Луч вниз с высоты +3 ярда над каждой точкой. Пишет в лог EDITOR_PROBE … hit_z dz.
EDITOR_SHOT_SEARCH=<текст>	Запрос в каталоге.
EDITOR_SHOT_SELECT=<guid>	Выбранный спавн.
EDITOR_SHOT_DIALOG=export|quit	Окно открывается с вопросом об экспорте или о несохранённых изменениях.

Пример: EDITOR_SHOT=shot.png EDITOR_SHOT_DIST=8 cargo run -p editor-app -- p.json --at -8935,-129.5,84. Снимок открывается инструментом чтения изображений.

Правила

• Benilla закреплён. Переход на новый коммит Benilla — отдельный коммит: обновить BENILLA_REV, собрать, прогнать проверки и замеры на WMO (Крепость Штормграда -8439.98,329.392,122.579, Башня магов -9010.78,876.575,148.702). Не правь ../benilla: это чужой рабочий репозиторий. API Benilla не стабилен (../benilla/docs/CONTRIBUTING.md).
• Ядро vMaNGOS (/home/sindo/core, WSL) — репозиторий владельца, рабочая ветка development. Не коммить туда без явной просьбы. Тестовые миграции убирай из sql/content/migrations, тестовые строки — из локальной БД.
• Локальная БД. Контейнер можно запускать: wsl -e bash -lc 'cd /home/sindo/core/deploy/local && ./compose.sh up -d db'. Записывать в неё можно только миграциями и только в тестах, за которыми ты потом убираешь. Для изоляции SQL-теста используй явный DDL временных таблиц: MariaDB может отклонить CREATE TEMPORARY TABLE name LIKE schema.name при совпадении имён. Не используй --force для продолжения после ошибок подготовки; проверяй неизменность постоянных таблиц.
• Секреты. Пароль БД хранится в пользовательском профиле; старый .env git игнорирует. Не печатай его и не коммить.
• Стиль. Комментарии и сообщения коммитов на английском, в духе существующего кода: объясняют «почему», ссылаются на функции ядра или клиента. Подписи интерфейса на русском.
• Коммиты — небольшие, по одному шагу. В конце сообщения строка Co-Authored-By: с именем агента.

Особенности окружения (Windows + Git Bash + WSL)

• Git Bash переписывает аргументы вида /home/... в wsl. Перед такими вызовами ставь MSYS_NO_PATHCONV=1.
• Пути к Windows-файлам для .exe пиши как C:/..., не /c/....
• В heredoc через инструмент Bash обратные слэши могут схлопнуться. Пути с \\wsl.localhost пиши через файл или инструмент редактирования.
• В .env пути с обратными слэшами заключай в одинарные кавычки, иначе dotenvy не разберёт.