Решили: снимать по кадру на каждый экран каталога превью — прогон
Alebardium → UI → Screen Sheet, кадры в docs/lab/assets/ui-screens, манифест рядом. Экран
снимается поверх ЖИВОЙ панели, игровой интерфейс на время прогона прячется.
Почему: аудит ядра UI 23.08.2026 показал, что три самых частых класса претензий Макса — реф не отработан, метрика внутри одного элемента не сходится, элемент молча пропал — не ловятся ни одним из десяти статических гейтов. Гейт читает текст USS и реестры; «пропал задник» в тексте не виден. Отвергли изолированный стенд с подложкой: своей заливки у UI больше нет (задник рисует презентация материалом стола), и кадр со стенда показал бы экран на пустоте — то же решение, что принято для контактного листа элементов 05.08.2026.
Сказано: «Как мы фоткаем экраны каждый? Они же бывают разные. Создаются некоторые кодом, некоторые нет. Изучи. Мы все сможем норм создать и пофоткать?» (23.08.2026, сессия 14ae129e). Оттуда же принято правило достоверности: стенд и игра собирают экран одним кодом, иначе кадра нет.
Грабли: механизм был готов на четыре пятых и не осознавался как таковой. UiPreviewCatalog
уже держал пары «id → сборка со стендовыми данными», 21 экранный View уже собирался чистой
статической Build(данные), сцена стенда и хост существовали — не хватало последнего шага, съёмки.
Полдня разведки ушло на вывод «реестра экранов у нас нет», который оказался неверным: реестр был,
просто жил в DevTools под именем каталога превью.
Второе: часть записей каталога пересобирает экран заново, потому что настоящая сборка заперта
приватным методом в MenuRouter (13 методов Build*Screen). Кадр такого экрана показывает стенд,
а не игру. Это и есть цена God-класса, выраженная в картинке.
Владелец правды: UiScreenSheet.cs, UiPreviewCatalog.cs, пункт меню в
UiContactSheetMenu.cs.