Severity: MEDIUM — registry/consumer schema drift: the serial classifier requires platform == "espressif32" but the published registry emits "esp32", so matching profiles silently classify as None. The same trap will bite the upcoming WCH/CH32 registry rows.
Problem
family_from_usb_profile in crates/fbuild-serial/src/boards.rs:564-568:
if profile.platform.as_deref() == Some("espressif32")
&& profile.role == UsbDeviceRole::RuntimeCdc
{
return Some(Esp32NativeUsbCdc);
}The published FastLED/boards artifact (https://fastled.github.io/boards/usb-profiles.json, fetched 2026-07-21) emits "platform": "esp32" on its runtime_cdc rows (e.g. CH9102 1a86:55d4). The comparison never matches → those devices fall through to None and get the fallback DTR=true/RTS=true open profile instead of their intended family behavior.
Side effect is currently benign-ish (safe defaults), but it demonstrates that a registry row can silently miss its consumer. When WCH-Link/CH32 rows are added to the registry (see the FastLED/boards issue linked from the meta), the same drift would make them dead on arrival.
Fix direction
Pick one canonical spelling and enforce it on both sides: either normalize in the publisher pipeline (FastLED/boards) or accept both spellings in family_from_usb_profile with a comment. Add a contract test in fbuild that fetches (or fixtures) the published schema and asserts every platform value used in family_from_usb_profile comparisons actually occurs in the artifact — so the next drift fails a test instead of silently degrading.
Related cleanup: the test-only test_family_for_vid_pid (boards.rs:586-613) hardcodes a (0x1A86, _) => Esp32ExternalUart wildcard that production does not have — tests are pinning behavior production doesn't implement; align or delete.
Acceptance
- CH9102-fronted board classifies as its intended family from the live artifact.
- Contract test fails if a
platform literal in the classifier has zero occurrences in the registry artifact.
From the 2026-07-21 CH32V bench-readiness sweep (deploy/serial audit pass).
Severity: MEDIUM — registry/consumer schema drift: the serial classifier requires
platform == "espressif32"but the published registry emits"esp32", so matching profiles silently classify asNone. The same trap will bite the upcoming WCH/CH32 registry rows.Problem
family_from_usb_profileincrates/fbuild-serial/src/boards.rs:564-568:The published FastLED/boards artifact (
https://fastled.github.io/boards/usb-profiles.json, fetched 2026-07-21) emits"platform": "esp32"on its runtime_cdc rows (e.g. CH91021a86:55d4). The comparison never matches → those devices fall through toNoneand get the fallback DTR=true/RTS=true open profile instead of their intended family behavior.Side effect is currently benign-ish (safe defaults), but it demonstrates that a registry row can silently miss its consumer. When WCH-Link/CH32 rows are added to the registry (see the FastLED/boards issue linked from the meta), the same drift would make them dead on arrival.
Fix direction
Pick one canonical spelling and enforce it on both sides: either normalize in the publisher pipeline (FastLED/boards) or accept both spellings in
family_from_usb_profilewith a comment. Add a contract test in fbuild that fetches (or fixtures) the published schema and asserts everyplatformvalue used infamily_from_usb_profilecomparisons actually occurs in the artifact — so the next drift fails a test instead of silently degrading.Related cleanup: the test-only
test_family_for_vid_pid(boards.rs:586-613) hardcodes a(0x1A86, _) => Esp32ExternalUartwildcard that production does not have — tests are pinning behavior production doesn't implement; align or delete.Acceptance
platformliteral in the classifier has zero occurrences in the registry artifact.From the 2026-07-21 CH32V bench-readiness sweep (deploy/serial audit pass).