vid-ingest: final end-to-end verification (after #723–#739 close) #740

Part of #722. Blocked on every sibling vid-ingest issue (#723–#739) being closed first.

Goal

Once every per-vendor ingest sub-issue under #722 is closed and the merged online-data/usb-vid.json carries entries from each registered source, run a single end-to-end verification pass that:

1. Forces a fresh nightly run of the Update data workflow (workflow_dispatch from main) so online-data is republished with the union of every new tier-N fetch.
2. Confirms every major vendor's VID resolves to its expected vendor name via plain HTTP — i.e. curl https://raw.githubusercontent.com/FastLED/fbuild/online-data/data/usb-vid.json | jq '."VVVV".vendor' returns the expected string.
3. Generates a curated list of common board names that real fbuild users plug in, runs each through the published SQLite-over-HTTP database on the www branch (or the equivalent JSON path), and records the hit rate.
4. Writes the results table back into THIS issue body (edit-in-place), then stops. Do NOT close feat(online-data): ingest per-board VID:PID tables from upstream vendor manifests #722 when finished — the meta issue stays open for ongoing curation.

Step 1 — republish online-data

gh workflow run update-data.yml --repo FastLED/fbuild --ref main
gh run watch "$(gh run list --repo FastLED/fbuild --workflow update-data.yml --branch main --limit 1 --json databaseId --jq '.[0].databaseId')" --exit-status

Expected outcome: the Summary step's table shows every tier as success, and the publish step pushes a new commit to online-data (and a sibling commit to www).

Step 2 — vendor-VID resolution sweep

For each of the 17 vendors filed under #722, fetch the published JSON and assert vendor-name resolution. Fill in the Vendor-resolution results table at the bottom of this issue. Each row needs:

• VID — lowercase 4-hex
• Expected substring — e.g. "Espressif" for 0x303A
• Actual — the live vendor value at that VID
• Status — ✅ / ❌

Use:

for vid in 303a 2e8a 0483 1fc9 1915 03eb 04d8 10c4 2544 1a86 0403 1cbe 045b 2341 2a03 239a 1b4f 16c0 2886; do
  printf '0x%s: ' "$vid"
  curl -sS "https://raw.githubusercontent.com/FastLED/fbuild/online-data/data/usb-vid.json" \
    | jq -r --arg v "$vid" '.[$v].vendor // "<missing>"'
done

Step 3 — common board names → VID:PID hit rate

The point of the per-vendor ingest work was to push the headline "what board is this VID:PID?" query to high accuracy. This step measures actual accuracy.

Generate a list of common board names (target ≥ 40) drawn from the fbuild build matrix + popular community boards. Suggested seed list:

arduino uno, arduino leonardo, arduino mega, arduino micro, arduino zero, arduino due, arduino mkr1000, arduino nano every, arduino nano 33 iot, arduino nano matter, arduino giga r1,
arduino uno r4 wifi, arduino nano rp2040 connect,
esp32 devkit v1, esp32-s2 saola, esp32-s3 devkitc-1, esp32-c3 devkitm-1, esp32-c6 devkit, esp32-h2 devkit, esp32-p4 function ev,
unexpected maker tinys2, unexpected maker tinys3, unexpected maker feathers3,
lilygo ttgo t-display, lilygo t-watch,
adafruit feather nrf52840 express, adafruit feather nrf52840 sense, adafruit itsybitsy nrf52840, adafruit circuit playground bluefruit, adafruit clue, adafruit matrix portal m4, adafruit qt py m0, adafruit qt py rp2040,
raspberry pi pico, raspberry pi pico 2, raspberry pi pico w, raspberry pi debug probe,
seeed xiao rp2040, seeed xiao nrf52840, seeed xiao mg24, seeed xiao esp32-s3,
sparkfun pro micro, sparkfun thing plus matter, sparkfun redboard artemis,
teensy 3.2, teensy 4.0, teensy 4.1, teensy lc,
nucleo f429zi, nucleo f439zi, bluepill stm32f103c8, blackpill stm32f411ce,
nice!nano, nrfmicro,
nxp lpc845-brk, lpcxpresso845-max,
ch32v003 evt

For each name, do a string-match query against the published board data (FTS5 on www's vidpid + vid_vendor tables, OR direct JSON grep on vendor_boards.json / pio-boards.json). For each board:

• Find the best fbuild-known board id (fuzzy match on board.name).
• Look up its MCU → VID via mcu_to_vid heuristic OR direct VID:PID via the future usb-board-pids.json (from feat(online-data): ingest per-board VID:PID tables from upstream vendor manifests #722 work).
• Record whether at least one credible VID:PID candidate is returned.

Fill in the Board-name match results table at the bottom.

Step 4 — write results back into this issue

When both tables are filled and tallied, edit THIS issue body in place via:

gh issue edit <THIS-ISSUE-NUMBER> --repo FastLED/fbuild --body-file <updated-body.md>

Then leave the issue open — closing it would suggest the work is permanently done; in reality the curation is an ongoing maintenance burden, so this issue stays open as the "current state of the world" pin.

Critically: do NOT close meta issue #722. It stays open as the perpetual curation tracker.

Vendor-resolution results

Filled from published online-data/data/usb-vid.json after workflow dispatch. Status is substring match against the expected vendor label.

Workflow run: https://github.com/FastLED/fbuild/actions/runs/28538427206 (main c99579e, online-data ac2d1ce, www 09b6e4b, manifest generated_at 2026-07-01T18:28:44Z).

Cross-reference: the same VID:PID rows also land in FastLED/boards site branch's usb-ids.json + usb-vids.proto.zstd (public portal at https://fastled.github.io/boards/) via FastLED/boards@df925a7f on the other branch.

Tally: 19 / 19

Board-name match results

Filled from the published JSON path (pio-boards.json, usb-vid.json, mcu_to_vid.json) plus the current fbuild board assets under crates/fbuild-config/assets/boards/json. A board id is considered first-party fbuild support when it exists in that repo path. Follow-up PR #917 back-fills the 6 ⚠️ PID follow-up rows from the previous verification (2026-06-30) by (a) adding build.vid/build.pid to 3 existing fbuild boards and (b) creating 5 new first-party board JSONs. FastLED/boards commit @df925a7f on the other branch adds the same 8 rows to the public boards portal (https://fastled.github.io/boards/).

Tally: 57 / 57 confirmed VID:PID hits.

Back-fill notes (2026-07-01):

The 6 ⚠️ PID follow-up rows and 3 _not in fbuild boards_ rows from the previous verification (2026-06-30 snapshot at fbuild online-data fdd76d3) were resolved by #917 + FastLED/boards@df925a7f:

• esp32-s2 saola — added build.vid=0x10C4 build.pid=0xEA60 (CP2102 bridge, per Espressif Saola-1 user guide).
• sparkfun thing plus matter — added build.vid=0x1366 build.pid=0x0101 (onboard J-Link OB, Segger PLUS variant; physical-device confirmation of the exact PID variant recommended for future).
• ch32v003 evt — added build.vid=0x1A86 build.pid=0x8010 (bundled WCH-LinkE in RISC-V mode; ARM mode is 0x8012, requires mode-switch to flash).
• adafruit qt py rp2040 — created crates/fbuild-config/assets/boards/json/adafruit_qt_py_rp2040.json with 0x239A:0x80F8 (adafruit/circuitpython mpconfigboard.mk).
• seeed xiao rp2040 — created seeed_xiao_rp2040.json with 0x2E8A:0x000A (earlephilhower/arduino-pico board manifest).
• seeed xiao mg24 — created seeed_xiao_mg24.json with 0x2886:0x0062 (SiliconLabsSoftware/arduino boards.txt).
• nice!nano — created nice_nano.json with 0x239A:0x00B3 (Adafruit_nRF52_Bootloader nice_nano/board.h).
• nrfmicro — created nrfmicro.json with 0x1209:0x5284 (Adafruit_nRF52_Bootloader nrfmicro/board.h + pid.codes/1209/5284).

Non-fbuild rows kept:

• raspberry pi debug probe — 0x2E8A:0x000C is resolved via the upstream Raspberry Pi VID:PID table. Not added as a first-party fbuild board because it is a debug probe accessory, not a compilation target.

Done criteria

• Both result tables above are fully filled in (no _pending_ rows remain).
• Tallies posted as the final lines of each table.
• The issue stays open with the populated tables as its body (so it acts as the "last verified state" pin).
• A short comment is appended to feat(online-data): ingest per-board VID:PID tables from upstream vendor manifests #722 linking back here with the headline hit-rate number.

Out of scope

• Closing feat(online-data): ingest per-board VID:PID tables from upstream vendor manifests #722. That issue is the perpetual curation tracker — every new vendor that ships fbuild-relevant USB devices in the future opens a new sub-issue under it, and this verification runs again.
• Adding any new vendor sub-issues during this work. That's separate maintenance.