Решили: правку .cs проверяет scripts/compile-check.ps1, а не редактор. Скрипт собирает
затронутые сборки Roslyn’ом из установки Unity по готовым командам компиляции, которые редактор уже
написал в Library/Bee/artifacts/*.dag/*.rsp. Замер: одна сборка 1.7–3 секунды, все двадцать две —
44. Правило внесено в CLAUDE.md как HARD.
Почему: цикл «сохранил скрипт → редактор снова готов» стоит от 10 до 56 секунд, при том что сама компиляция занимает 1–3 миллисекунды — платим за перезагрузку домена. Для параллельной сессии это двойная беда: агент либо ждёт чужой редактор, либо морозит Максу тулинг ошибкой сборки. Скрипт отвечает на единственный нужный вопрос и редактора не касается.
Отвергнутые альтернативы, каждая по своей причине:
- Дробить asmdef — нечего дробить, компиляция и так три миллисекунды.
- Hot Reload (SingularityGroup) — снят решением Макса; вдобавок он лечит правки тел методов, а агентский профиль это новые типы и поля, где перезагрузка случается всё равно.
- Генерировать
.csprojи собиратьdotnet build— лишний слой:.rspуже содержит все ссылки, дефайны и анализаторы ровно в том виде, в каком их считает сам редактор. - Ждать CoreCLR, который убирает перезагрузку домена вовсе — альфа заявлена на Unity 6.8.
Грабли: список исходников нельзя брать из .rsp — он зафиксирован на момент последней сборки
редактором, и новый файл в него не попадает, то есть молча не проверяется. Скрипт сканирует папку
asmdef с диска, исключая поддеревья с собственным asmdef. Второе: -out обязан уезжать во временную
папку вне репозитория — писать в артефакты Bee значит ломать инкрементальность самой Unity. Третье:
.rsp устаревает по составу ссылок после установки пакета или заведения нового asmdef; скрипт
сравнивает даты с manifest.json и предупреждает, лечится одним открытием редактора.
Владелец правды: scripts/compile-check.ps1 (механизм и ограничения — в шапке файла),
scripts/unity-cli.ps1 → Get-UnityEditorRoot (единственный владелец пути к установке),
CLAUDE.md §«Правку .cs проверяет скрипт».