Shop catalog: 100% coverage, verified.

The Shop was only showing ~20% of every store's menu — 5,562 of 28,327 in‑stock SKUs fleet‑wide. It wasn't random: the bigger the store, the worse it got. Orillia showed 127 of 1,294 products (10%). Red Hill, 125 of 1,064 (12%). Every large store sat between 10–20%; the small SESH stores around 63–66%.

The tell was that every store loaded ~120 products regardless of its real size — a 108‑SKU store and a 1,294‑SKU store both showed ~120. That's a system ceiling, not a coincidence.

Root cause: the Shop browsed Dutchie's consumer menu() API, which returns ~20 products per query and cannot paginate (every page/cursor argument is rejected). To get more, the app fanned out across ~10 categories (~20 each) → ~120 products total. Past that, there was no way to ask menu() for "the rest."

Why not just call it more? An exhaustive fan‑out (category × brand × strain × subcategory) still tops out near ~50% on big stores and costs ~84 API calls per store — far too slow for a live page, and it still never reaches 100%.

So 100% was structurally impossible through the API the Shop was using. It needed a different door.

The Shop now reads a worker endpoint, /api/catalog, which calls Dutchie's paginated filteredProducts feed (in‑stock only — the same one CannaSync used). The catch: that feed is behind Cloudflare's bot wall for normal calls — so we call it from inside our own Cloudflare worker, which clears the wall. Then:

• Full pagination — every page of every store, 350 ms between pages so a big store isn't a burst that re‑trips Cloudflare.
• D1 cache with last‑good fallback — if Dutchie or Cloudflare ever hiccups, the store serves its last full catalog instead of going blank.
• Steady warmer — a background daemon refreshes one store at a time, so the live page always reads a warm cache and never cold‑fetches during traffic.
• In‑stock only — matches Dutchie's own rule (quantity below 1 = not available), so we never show what can't be sold.

Two locations correctly show 0 — Laurelwood and St. Catharines return totalCount: null from Dutchie itself (no live menu yet — coming‑soon). 0 is the right answer there, not a miss.

Going to 100% surfaced a second, hidden bug: checkout blocked cart items as "no longer available." Cause was ours — the catalog built a placeholder variant id (id|size) where Dutchie's real one is id~size, and the price step searched Dutchie by the product's display name (which doesn't match). Both are now resolved by matching on the option and trusting Dutchie's own add‑confirmation. Re‑tested end‑to‑end on a live store: cart → checkout → Dutchie hand‑off opens with the right items and prices. Genuinely unavailable items still correctly block.