Решили: процедурная генерация получила границу применения из ТРЁХ полос — считаем поверхности и
формы, собираем по сиду из авторских частей, рисуем руками смысл — плюс правило разделения сим- и
показ-рандома. Правило живёт в code-standards §8, инструментом-контуром (скиллом) не оформляется.
Почему: процедурка уже работала в шести местах проекта (формы удара, разлёт осколков, топология
карты, пять шейдеров карты, запекатель панелей UI, вершинная отрисовка в Painter2D/Shapes), но
каждое гнездо изобреталось отдельно и своего правила не знало — граница существовала только в
докстринге PanelTextureBakerWindow, то есть не обязывала никого.
Отвергли скилл procedural: наши контуры нарезаны по подсистемам (uitk, gamefeel-vfx,
data-authoring), а процедурка — метод поперёк всех. Скилл по методу немедленно дал бы спор за
владение (процедурную панель ведёт uitk или procedural?), то есть факт с двумя владельцами —
ровно то, что запрещает HARD про единый источник правды. Вместо скилла: правило в каноне +
библиотека Guildmaster.Procedural, которая заставляет, а не напоминает.
Отвергли двухчастное правило («математика делает материал и форму, человек — смысл»), которое я
сформулировала утром того же дня. Оно ломается на первом же нашем случае: face-DTO Сосуда из
character-art-flat-storybook — это не генерация формулой и не рисование, а комбинация авторских
частей по сиду. Правило, врущее на первом применении, хуже отсутствия правила.
Сказано: «Я понял, что оба недооценивали процедурную генерацию для текстур или еще каких-то
нужны. […] Имхо, это сильно помогает разработке и надо поречерчить эту тему.» и днём раньше по UI:
«Т.е. да, создавать для UI что-то процедурно - это правильный путь, который часто юзать будем,
думаю.» (02.08.2026, сессии f76789b3 и d2239d53). По самой границе: «Трехчастное - хорошо.»
Про иконки — вердикта нет, есть отсрочка: «Хотя насчет проценудрных иконок я бы мб подумал, но
точно не сейчас, сначала - пайплайн» (02.08.2026, сессия f76789b3). Поэтому иконки записаны в
полосу «рисуем» как текущее положение дел, а развилка заведена в gdd/00-meta/open-forks.md, а не
закрыта его именем.
Грабли: три разных рандома в проекте обнаружились только при сведении инвентаря —
XorShiftRng в симуляции, sin-хеш в шейдере осколков, свой шум в запекателе панелей. Каждый
писался с нуля, и по отдельности каждый правильный: разница не в качестве, а в том, что одинаковая
на вид фактура в двух местах получается из разных формул и расходится при первой же правке. Само
разделение «сим-рандом против показ-рандома» было верным и работало, но существовало как комментарий
внутри одного шейдера — то есть вторая сторона шва о нём узнать не могла.
Отдельная грабля учёта: обсуждения в архиве диалогов дают перекошенную картину — по ним процедурка выглядит темой одного дня (02.08), хотя первое гнездо уехало в код 13.07. Инвентарь «где уже используем» собирается по диску, архив годится только как наводка на «почему так решили».
Владелец правды: Reference - Code Standards §8 и инвариант
в §1. Тестом инвариант «показ-рандом не течёт в симуляцию» ещё не закрыт — это долг фазы 2,
он появится вместе с Guildmaster.Procedural; до тех пор правило держится только доком, и это его
слабое место. Прецеденты в коде: SH_Vfx_HitForm.shader (сид гуляет по форме, но не по размеру),
SH_Sprite_Shatter.shader (обоснование безопасности sin-хеша), PanelTextureBakerWindow.cs
(цвет из палитры, детерминизм по сиду).