UX audit’s color-and-contrast pass flagged method/status badge fills (GET, POST, SMTP, PUB, SUB, READ) as probable hardcoded-color offenders. ClientScreen.kt was listed as a known hardcoded-color file, leading the audit to suspect that badge composables in the same module used raw Color(0x...) literals.
The audit’s inference was based on ClientScreen.kt appearing in the hardcoded-color offender list, not on direct inspection of the badge composables. The badge rendering had already been tokenized before the audit ran: EditOutboundWebHook.kt, EditIncomingWebHook.kt, and EditMqtt.kt all wrap their badge labels in Surface(color = MaterialTheme.colorScheme.primaryContainer) (with per-method semantic variants for HTTP methods). No Color(0x...) literal exists in any badge composable.
No code change. Investigation confirmed the finding was already resolved. Issue closed.
When a file is listed as a “hardcoded-color offender,” inspect the badge/chip composables it delegates to separately — they may have been tokenized independently of the parent file. Surface(color = colorScheme.X) automatically propagates contentColorFor(colorScheme.X) to all LocalContentColor-reading descendants; text inside Surface is already on-color without needing explicit color =. Confirm token compliance by grepping for Color(0x in the badge composable file directly rather than inferring from the parent file’s status.