Add outcome-shopping-template: multi-vendor, outcome-based shopping orchestrator

[mconroy-cf]

Summary

Adds outcome-shopping-template — a multi-vendor, outcome-based shopping orchestrator that pairs with commerce-llms-txt-template.

Takes a natural-language shopping intent (e.g. "outfit my 3-year-old for skiing"), decomposes it with Workers AI into component product needs, and composes a cross-merchant recommendation from each merchant's commerce-llms-txt-template /api/products endpoint.

The React SPA at / runs the full decompose → match → compose pipeline against the bundled sample catalog, so the template demos itself end-to-end on first deploy.

What's in the template

• Worker at src/orchestrator-worker/index.ts serving /api/shop, /api/catalogs, /api/merchants, /llms.txt, and an /api docs endpoint.
• React + Vite SPA at src/react-app/ via @cloudflare/vite-plugin — single vite build produces both the SPA (as Workers Static Assets) and the Worker bundle.
• Required CATALOG_CACHE KV binding with a placeholder ID in wrangler.jsonc. No optional fallback. Cache key incorporates the merchant fingerprint so changing MERCHANT_ENDPOINTS busts the cache automatically.
• Bundled sample catalog (3 merchants, 9 products) matching the shape emitted by commerce-llms-txt-template, served when MERCHANT_ENDPOINTS is empty or every configured merchant fails.
• Default AI model: @cf/google/gemma-4-26b-a4b-it, consistent with where we landed on commerce-llms-txt-template.
• 8 vitest tests via @cloudflare/vitest-pool-workers.
• Playwright E2E spec at playwright-tests/outcome-shopping-template.spec.ts.

Applying feedback from #968

Both new templates deliberately pre-apply the KV-required + SPA-on-top-of-API feedback from #968 so this reviewer doesn't have to re-litigate the same points.

Verification

• pnpm turbo run check --filter=outcome-shopping-template — passes
• pnpm turbo run test --filter=outcome-shopping-template — 8/8 passing
• pnpm run check:templates — passes
• pnpm run check:prettier — clean

[mconroy-cf]

Two updates since you received this.

Correctness fix in 49bb23e — switched the default AI_MODEL from @cf/google/gemma-4-26b-a4b-it to @cf/meta/llama-3.3-70b-instruct-fp8-fast. Gemma 4 is a reasoning model; called via ai.run({messages}) it writes to message.reasoning and frequently hits max_tokens before emitting message.content, so decomposition silently falls back to single-need mode and the template looks broken on first deploy. Llama 3.3 70B FP8 Fast returns the expected JSON reliably under the same call shape. The response extractor already handled both wire formats so no other code changed. Template tests, check, check:templates, and check:prettier all pass.

Reference implementation at gitlab.cfdata.org/mconroy/outcome-shopping has moved well past this template since the PR opened — streaming endpoint, stateful MCP agent (Durable Object per session), real Shopify merchants via a multi-tenant proxy, /demo auto-tour. Intentionally a separate artifact: this template is the minimal starter, the gitlab repo is where we've taken the concept further. Flagging it in case it's useful context while you review, not a request to roll any of it in.

[mconroy-cf]

Pushed 3499954: hash the catalog cache key so it fits KV's 512-byte key limit.

The previous cacheKey() concatenated each merchant's name + URL into an unbounded fingerprint. A fresh deploy with more than ~5 merchants (each URL ~70-100 chars) can exceed 512 bytes — KV.put() rejects the write and the orchestrator silently bypasses the cache on every request. SHA-256 hashing produces a fixed 64-char hex suffix that always fits.

Caught while reviewing drift between the gitlab reference implementation and this template — the gitlab side already had the fix. pnpm turbo run check --filter=outcome-shopping-template --force, pnpm run check:templates, and cd outcome-shopping-template && pnpm test all pass.