Journal - Sorting Claim Retracted Until Measured In Play

Решили: утверждение из записи 2026-07-30-two-units-parts-never-interleave — что ордер группы разводит юнитов между собой, а ось лишь тай-брейк — снимается как непроверенное. Оно было выведено из документации и структуры префаба, а не из измерения. Запись не правится (журнал append-only), но читать её надо вместе с этой.

Что подтверждено измерением и остаётся в силе:

• Внутренний порядок частей корректен: тень −1, торс 0, ноги 1–3, меч 2, плечи 4, рука 5, предплечье 6, голова 7, щит 8; Z у всех нулевые.
• SortingGroup внутренний порядок не ломает: один юнит с группой и без даёт идентичный кадр, 0 пикселей разницы.
• «Торс поверх всего» на цветных пробах — это щит с ордером 8, а не дефект сортировки.

Что не подтвердилось: в offscreen-стенде перестановка ордеров групп местами (±1000 и ±30, при разной и при одинаковой Y) давала 0 пикселей разницы при живом контроле 30358 px от сдвига юнита; на паре юнитов части перемешивались. Если это верно, то SetSortingOrder из UnitView не влияет ни на что, а порядок держится только осью — и тогда схема сломается на юнитах с РАЗНЫМИ наборами частей, потому что у одинаковых юнитов ордера частей совпадают и их случайно разводит ось.

Грабли — про метод, и они дороже самой находки:

• Offscreen-стенд (своя камера + HideAndDontSave + Camera.Render() в edit mode) непригоден для вопросов о порядке отрисовки. Пять замеров подряд дали неинтерпретируемые результаты: маски поймали чужой юнит, стоящий у начала координат в открытой сцене; в кадр влезли хелсбары; bounds по неактивным рендерерам увели камеру в шесть раз; выбранная «точка перекрытия» оказалась прозрачной. Камера при этом не виновата — с UniversalAdditionalCameraData результат тот же, а transparencySortMode наследуется корректно.
• Численный критерий по доминирующему каналу («красный ярче синего») врёт на кромках и контурах. Работает только дифференциальный критерий: меняем ОДНО и смотрим, изменился ли кадр целиком, плюс обязательный контрольный прогон, который ОБЯЗАН дать разницу.
• Порядок отрисовки проверяется в play-mode, где ордер раздаёт живой UnitView, а не в редакторном стенде.
• Из документации (у нас не измерено): ось CustomAxis имеет низший приоритет и действует только между рендерерами с одинаковыми слоем и ордером; внутри группы индивидуальное расстояние до камеры не учитывается.

Владелец правды: SpriteSortingSetupTests — только структура (группа есть, части в одном слое, ось в проекте, рендереры пайплайна в Default); фактический порядок на экране не покрыт ничем и ждёт замера в play-mode.