Symptom

Every settings screen rendered structural subsection labels (“Input Nodes”, “Backend”, “Schedule”, “Action”, etc.) in primary blue (#8AB4F8) via an ad-hoc Text(style = titleSmall, color = primary) pattern. This competed visually with interactive elements (tabs, links, selection states) that also use primary, flattening the hierarchy on dense screens. An existing SectionHeading composable existed but itself used colorScheme.primary, so callers that had already migrated to it still rendered the wrong color.

Root cause

SectionHeading.kt was created to centralise the section-header style but was authored with color = MaterialTheme.colorScheme.primary. The correct token for structural sub-labels is colorScheme.onSurfaceVariant (a gray that reads as secondary/subordinate). Because the composable encoded the wrong token, and because adoption was incomplete (~12 files still used the inline Text(titleSmall, primary) pattern instead of calling SectionHeading), neither fixing the token nor consolidating callers was sufficient on its own.

Fix

• Changed SectionHeading.kt to color = MaterialTheme.colorScheme.onSurfaceVariant.
• Replaced all remaining inline Text(style = titleSmall, color = primary) section-header call-sites across 12 files with SectionHeading(...), adding the import where missing.
• Left colorScheme.primary intact for non-section-header uses: button borders, icon tints, badge indicators, interactive label text (e.g. tag chips in EditLambda, link text in PeerView).

Prevention

• A shared composable only eliminates color drift if every call-site uses it. When adding a new token-enforcing wrapper, grep for the raw inline pattern and replace in the same PR — don’t leave partial adoption as technical debt.
• The token for structural labels subordinate to primary actions is onSurfaceVariant, not primary. Reserve primary for interactive / actionable elements.