Решили: рельса ленты разделов — отдельный элемент .gm-tabbar__rail, а не border-bottom у
ленты. Плюс зафиксирована готча: НОВАЯ переменная, добавленная в tokens.semantic.uss, не доезжает
до живой темы в текущей сессии редактора, хотя в скомпилированном ассете она уже есть.
Почему: приём A («вкладка на рельсе») требует, чтобы рельса была ШИРЕ ленты — у Guildrun она
тянется почти во всю ширину кадра, пока табы центрированы. Границей такого не выразить: она обводит
ровно свой элемент. Вдобавок border-bottom тут просто не рисовался — resolvedStyle отдавал и
цвет, и толщину 2px, а замер пикселей кадра показал ноль линии. Выяснять причину дороже, чем
поставить элемент, который нужен и по существу.
Грабли: три штуки, каждая стоила времени.
- Правки USS на живой панели врут. Проба с литералом «сработала», проба со старой переменной вернула значение ПРЕДЫДУЩЕЙ пробы — панель держит старую распарсенную таблицу. Любой замер после правки темы делается только после выхода и входа в play; иначе выводы строятся на каше.
- Новая переменная резолвится не сразу.
--gm-color-railи--gm-color-surface-tab-litв скомпилированномStyleSheetприсутствуют (проверено обходомSerializedObject), ноvar()на них отдаёт пустое значение, тогда как СТАРЫЕ роли в том же правиле подставляются мгновенно — разделено подстановкой--gm-color-surface-accent-hoverв то же место. НиImportAssetсForceUpdateиImportRecursive, ни touch файлов, ни перезапуск play не помогают надёжно; у одной из двух переменных значение приехало само через несколько циклов. Лечится рестартом редактора. Практический вывод: заводя роль под живую правку, ожидай, что увидишь её эффект только в следующей сессии — и не переписывай из-за этого рабочее правило на литерал. - Активная вкладка висела над рельсой на 32px: отступ давала
.gm-settings__tabs(margin-bottom: var(--gm-space-4)), а не сама лента.
Владелец правды: components.uss (.gm-tabbar, .gm-tabbar__rail, .gm-tab,
.gm-tab--active), tokens.semantic.uss (--gm-color-rail, --gm-color-surface-tab-lit).