Sanity

Reused existing product queries to serve live search, category, and validation responses for the voice assistant. Verified live results for known terms and proper not-found behavior for unknown identifiers.

What worked

Existing catalog helpers transferred directly to voice needs, including server-side price re-read and stock rejection pattern.

Relied on the existing headless content backend for product titles, prices, stock status, and categories to ground assistant answers. Ran local checks with production dataset settings; no catalog schema changes were needed.

Inspected the catalog client used by checkout to confirm pricing was re-read server-side and to ensure bot checks did not change product lookup behavior.

What worked

Read-only usage was easy to reason about and required no changes for bot protection.

Reused the existing catalog access layer for keyword and category search plus single-product lookup behind a new search API consumed by voice tools. Live staging checks returned the expected products in both real and placeholder modes.

What worked

Existing catalog abstraction avoided duplicating pricing or availability logic for voice queries.

Reused as the live source of truth for product listing and detail lookups behind new voice catalogue endpoints. A local probe returned products successfully, confirming the voice path reads current catalogue data rather than a snapshot.

What worked

Existing product query helpers were reusable for voice endpoints and returned live results during verification.

Relied on the existing catalog accessors as the only source of product facts for assistant tool calls, so prices and availability are read server side. Only placeholder catalog data was available, so live catalog grounding was not observed.

What worked

Existing product accessors made grounded answers possible without new catalog plumbing.

Inspected how product images were already served from the catalog asset CDN through the image component. That finding removed the need for a separate object-storage migration and narrowed the work to the email queue.

What worked

The CDN-backed asset URL pattern was clear from the existing catalog and rendering code, which made the no-migration recommendation straightforward.

Used as the real product catalog behind assistant search, including price filtering and follow-up purchase resolution. Live checks returned relevant items after query handling was refined.

What worked

Catalog lookups supported multi-step search-to-checkout behavior and conversational follow-ups in live verification.

What got in the way

Initial broad queries returned weak matches until filtering logic was improved; service dataset configuration was also required.

Confirmed catalog is served from existing content backend so auth choice could stay auth-only with no catalog migration.

What worked

Separation between catalog reads and checkout logic made scope easy to limit.

Reused the existing product fetcher to back a read-only catalog lookup for voice function calls. Local verification was limited because required project configuration was not present in the environment.

What worked

Existing product access made a small read-only lookup straightforward without changing catalog logic.

What got in the way

Missing configuration prevented exercising live catalog data during build and browser checks.

Relied on existing CMS client for product data while keeping builds offline-capable with placeholder values; never connected to the live dataset. Catalog copy remained in source language.

What worked

Placeholder catalog path allowed the localized production build to complete without the service being up.

What got in the way

Client initialization at import time made the build sensitive to missing environment values until fallback handling was clarified.

Relied on the existing catalog integration as the source of product facts and prices. Confirmed server-side price re-reads stayed authoritative for checkout while analytics carried only non-sensitive product identifiers.

What worked

Catalog reads were stable enough to keep local builds working with placeholder config during verification.

Relied on existing catalog reads for product listing and detail pages to decide where to emit view events. No schema changes were needed. Build verification required placeholder project settings.

Reused the existing catalog client to ground assistant answers in real products, prices, stock, and slugs. Required local environment values before the build would pass.

What worked

Once environment values were present, catalog context reliably supported grounded prompts with an explicit no-invention instruction.

What got in the way

Production build failed when catalog credentials were absent because the client initialized with undefined values during static route collection.

Relied on existing catalog integration for product titles and descriptions. Interface strings were localized, but catalog content remained in its source language, leaving CMS-side translation as follow-up work.

What got in the way

Catalog content did not become multilingual through storefront message files alone.

Reused the existing catalog client as grounding context for drafted answers and reviewed its client module to follow established configuration patterns.

What worked

Thin client plus existing fetch helpers made it straightforward to ground drafts in catalog data and short-circuit low-value inputs before the expensive call.

Planned catalog localization with per-language fields and English fallback so merchandising can translate product copy separately from UI strings. Local verification used placeholder catalog data with translated titles; never ran against the live dataset in the record.

What worked

Field-level localization pattern with fallback was clear to implement without later code changes.

Reused the existing catalog fetch as grounded context for answers, made client creation lazy so builds pass without credentials, and verified pages rendered with fallback data.

What worked

Once lazy, the existing product fetch supplied compact fields suitable for grounding, and fallback data kept local builds and page checks unblocked.

What got in the way

Import-time client creation failed the production build when catalog credentials were absent, requiring lazy initialization and placeholder fallback handling.

Followed the existing server-side catalog access pattern so chat answers use freshly read catalog data and degrade gracefully on outage instead of trusting client prices.

What worked

Established catalog client pattern made grounding and graceful degradation simple to implement.

Checked content client setup while reviewing production readiness. Placeholder project identifier forced sample catalog behavior, so real catalog could not be confirmed without a production project value.

What worked

Fallback behavior for missing configuration was explicit and easy to understand.

What got in the way

Production catalog verification was blocked pending a real project identifier.

Planned and used per-locale catalog title and description fields with English fallback so missing translations never break product pages. Live locale page checks confirmed translated catalog copy rendered correctly.

What worked

Fallback design kept pages resilient when a locale lacked catalog copy, and adding a future market reduces to adding fields plus a dictionary.

Relied on the existing pattern of serving product images from the CMS CDN through the framework image component, keeping media off the application server.

What worked

No media migration was needed because images were already CDN-backed.

Relied on the existing content backend and product catalog as grounding context for assistant answers, with environment placeholders supplied for local runs and builds.

What worked

Existing catalog structure made it simple to ground responses without new content plumbing.