USB registry gap: FTDI FT232H 0403:6014 missing from usb-vids.proto.zstd

[zackees]

Gap

0403:6014 (FTDI FT232H USB-UART) is not present in the published
usb-vids.proto.zstd artifact. It is the only VID:PID that FastLED still
carries locally which the registry cannot resolve.

Verified against the live artifact fetched 2026-08-22 from
https://fastled.github.io/boards/usb-vids.proto.zstd (36 vendors, 1056
products). The FTDI vendor entry exists but carries only two products:

FTDI vendor name: FTDI
  0403:6001  Digilent chipKIT UNO32
  0403:6010  Shared USB identity (12 products)

A registry-wide scan for PID 6014 under any vendor returns nothing.

Why it matters

FastLED is retiring its hand-maintained USB tables in favour of this registry
(FastLED#3836). Auditing FastLED's ci/util/port_utils.py and
ci/util/serial_probe.py against the published artifact gives 14/15
resolved — this entry is the sole blocker to declaring the migration
complete and freezing the local tables outright.

Until it lands, BOARD_FINGERPRINTS in FastLED's ci/util/serial_probe.py
cannot drop its (0x0403, 0x6014): "FTDI FT232H USB-UART" row without losing
the ability to label an attached FT232H adapter.

Requested

Add 0403:6014 — FTDI FT232H (single-channel Hi-Speed USB to
UART/FIFO) — on the appropriate data branch (vendors looks right, since this
is a bare bridge chip rather than a board), so site.yml republishes it into
the artifact.

Verification after the fix

curl -fsSLo usb-vids.proto.zstd https://fastled.github.io/boards/usb-vids.proto.zstd
# decode and confirm 0403:6014 resolves to an FT232H product name

Then cascade: cut an fbuild release that ingests the refreshed artifact and
move FastLED's fbuild==X.Y.Z pin (pyproject.toml + uv lock).

[zackees]

Context for this gap:

• docs(usb): make FastLED/boards the documented VID/PID source of truth FastLED#3965 documents FastLED/boards as the VID/PID source of truth, freezes the two legacy local tables, and adds ci/util/audit_usb_registry.py — the script that surfaced this gap. It exits non-zero while 0403:6014 remains unresolvable, so this issue is what currently keeps that audit red.
• docs(usb): document the boards artifact transport and downstream cascade fbuild#1351 documents the artifact transport and the downstream cascade on the fbuild side.

Once 0403:6014 is published, re-running uv run python ci/util/audit_usb_registry.py in FastLED should report 15/15 and the FT232H literal can be deleted from ci/util/serial_probe.py.

[zackees]

Published. 0403:6014 is now live in the catalogue.

Added as a curated record on the other data branch (ftdi_bridge_pids.json, commit c126714), verified through builders/extract_other.py before pushing, then Build site run 32598169110.

Resolving downstream:

OK   0403:6014  FTDI FT232H  -> FTDI / FTDI FT232H (single-channel Hi-Speed USB to UART/FIFO)

15/15 resolve from FastLED/boards

No fbuild release was needed — it fetches the catalogue at runtime, so the new identity reached the consumer on the next cache refresh.

Worth noting for the process: filing this as an issue was the wrong call on my part. We own this repo, so pushing the record is the support path — the whole round trip was one commit and about four minutes. Both FastLED's agents/docs/usb-vid-pid-registry.md and fbuild's CLAUDE.md now say push immediately rather than file and wait.

[zackees]

Follow-up on the process point: #61 amends design.md so the next person doesn't repeat my mistake here.

The "PR-based board contributions" anti-goal ("we mirror, we don't curate-by-PR") read as a blanket ban on human-authored data, which is why I filed this issue instead of just pushing the record. That anti-goal is now narrowed to what it actually protects — don't fork mirrored board definitions, since those diverge on the next sync — with an explicit carve-out stating that curated USB identity records on other are pushed directly, verified with extract_other.py first.

This issue is cited there as the worked example.

[zackees]

Follow-up on the process point: #61 amends design.md so the next person does not repeat my mistake here. The PR-based board contributions anti-goal read as a blanket ban on human-authored data, which is why I filed this issue instead of just pushing the record. It is now narrowed to what it actually protects — do not fork mirrored board definitions, since those diverge on the next sync — with an explicit carve-out stating that curated USB identity records on other are pushed directly, verified with extract_other.py first. This issue is cited there as the worked example.