Symptom

The Color Trigger chip showed a neutral grey swatch in the unconfigured state, which was visually indistinguishable from a hardcoded color literal but was actually the midpoint of the full 0–255 range per channel (Color(0xFF7F7F7F)). The editor preview had no way to distinguish “user hasn’t narrowed a range yet” from a configured range that happens to span the full spectrum.

Root cause

EditColorTrigger.kt had no concept of “configured vs unconfigured” for the editor preview Box — it always rendered Color(meta.midpointArgb().toInt()). The chip used an ad-hoc isColorSet expression inline without sharing it with the editor, so the two surfaces drifted: the chip gained a tokenised placeholder (fix #594) but the editor preview didn’t.

Fix

• Extracted ColorTriggerMetaData.isColorSet(): Boolean as an internal extension in EditColorTrigger.kt (avoids duplicating the channel-bound check).
• Chip ColorChip now calls it.isColorSet() instead of the inlined expression.
• Editor preview Box now uses colorScheme.outlineVariant fill + a 1 dp colorScheme.outline border when isColorSet == false, and the runtime midpoint colour when the user has narrowed at least one channel.
• RGB slider colours (Color(0xFFD32F2F/388E3C/1976D2)) are retained as intentional semantic channel indicators — they must be channel-coloured and cannot be mapped to a colorScheme role without losing their meaning.

Prevention

• When adding a composable with an “unset” state, ensure both the chip and the editor views share the same “is it configured?” predicate rather than each inlining their own copy.
• Extract configuredState predicates as named functions so tests can pin them without going through a full Compose render.
• ColorTriggerChromeTest guards that isColorSet() returns the right value for boundary inputs and that the unset swatch resolves to outlineVariant.