JLCPCB Parts Library

Fixed, and live. You were right on both counts, and each had its own silent cause.

1. is_basic was false for every part in the catalogue, all 634,264 of them

Two mistakes, neither of which ever raised an error:

• The flag came from the wrong field. Our build ran CDFER's generate-database.py, which sets basic by matching a scraped CSV. That CSV stopped matching: every nightly run since 2026-08-26 printed Basic Parts Corrected: 0 into a log nobody reads. Upstream's own field, library_type (base / expand), was correct for all five of your parts the whole time. basic now derives from it.
• Every stock number was undated. The adapter ran an integer unix timestamp through strftime('%s', ...), which returns NULL, so last_update was 0 on every row. Nothing could tell you a stock figure was from June.

Your five parts, from the live service now:

(Your report had C25744 at 1,256,270 from our snapshot against 21,539,575 on the live site. We now read 21,529,252, straight from JLCPCB.)

2. Stock: dated per part, and the Basic set refreshed from JLCPCB nightly

The catalogue comes from a public crawl that re-reads JLCPCB over months, so one part can be a day old and the next a hundred days old. One freshness number per snapshot was never honest enough:

• Every part now carries stock_as_of and stock_age_days; every response carries a snapshot block with the build time.
• JLCPCB's entire Basic library is 351 parts, which their own endpoint will list. Since that set is what decides the bill, it is now refreshed straight from JLCPCB nightly at 04:30, in four requests. 350 of the 351 refreshed just now in 9 s. The one we cannot flag is C25804, which is not in the upstream catalogue at all.

3. A basic-only filter, end to end

is_basic existed on the API but was filtering the fetched page rather than the search. Basic is 351 parts out of 634k, so it almost always ranks below the page: the filter saw none and answered "none".

$ adom-jlcpcb search "0402 10k resistor" --basic
C25744  0402WGF1002TCE  21,529,252 in stock, as of 2026-10-05

$ adom-parts-search search "0402 10k resistor" --basic
Mouser: 3 hit(s) | DigiKey: 0 | JLCPCB: 1 hit(s) -> 0402WGF1002TCE

The unfiltered search still returns the two Extended 10k parts it always did, so this is the filter working rather than a reordering. --basic and --preferred are on search, category-search and list, and on adom-parts-search (where it narrows the JLCPCB column only, since Mouser and DigiKey have no equivalent). The API accepts is_basic, basic, libraryType=basic and library_type=base, because guessing which spelling we picked is not the caller's job.

4. A live single-part lookup

adom-jlcpcb part <LCSC or MPN> reads one part from JLCPCB directly (their public parts endpoint, no key, no quota), says when our snapshot disagrees, and falls back to the snapshot if JLCPCB cannot be reached. It is never used to enrich a search, because that would be one request per result on someone else's service.

$ adom-jlcpcb part C25744
OK: JLCPCB now: 0402WGF1002TCE BASIC, 21,529,252 in stock
differs: stock: snapshot 1,256,270 (as of 2026-06-23), JLCPCB 21,529,252 now

--offline answers from the snapshot alone. SKILL.md had documented this verb, including MPN lookups, before it existed; it exists now and takes both.

Shipped

adom-jlcpcb 1.0.9 and adom-parts-search 2.0.17 are published, the service is deployed, the 13-test smoke suite passes, and the live snapshot was backfilled in place rather than waiting for tonight's build.

What is still imperfect: parts outside the Basic set still carry whatever stock date upstream last gave them, which today can be ~100 days. The fix for a specific part is adom-jlcpcb part, which asks JLCPCB. Refreshing all 634k live is not something I will do to their service; if Extended stock accuracy starts costing real money, the honest next step is a licensed data source, and that is worth a separate conversation.