Sass Variable Overrides vs CSS Custom Properties for Bulma Runtime Theming

Bulma v1 documents two customization approaches: overriding Sass variables before compilation and overriding CSS custom properties at runtime. A project that needs both structural global changes and dynamic theme switching must decide how to divide responsibility between these layers.

The unresolved behavior concerns the incomplete mapping between Sass variables and CSS custom properties. Bulma derives CSS variables from Sass, but it does not clearly document which variables are exposed. Sass changes are structural and require a rebuild, while CSS variables support dynamic theming without recompilation. Relying only on CSS variables may fail to affect properties computed or hardcoded at build time, while relying only on Sass variables blocks runtime updates.

This creates a trade-off around maintaining parallel customization layers. Duplicating values in both Sass and CSS risks drift, whereas using only one layer may leave certain properties immutable without a full rebuild. The boundary between compile-time and runtime control is version-sensitive and not fully specified; confirming which properties respond to each layer requires practical verification against the compiled output.

Which layer should govern structural tokens like border radius when runtime theme switching is also required? How can a developer determine whether a specific Bulma property is exposed as a CSS custom property without inspecting the generated stylesheet? Is there a documented pattern for preventing value drift across both customization layers?