Build a custom storefront

 Browser                Your storefront server                   Kentro
 (pages, your cookie)   (API key; buyer or guest
                         tokens per session)

 sign in    ----------> POST /auth/login/customer  ------------>  authentication
 browse     ----------> POST /catalog.list         ------------>  Store API
 add to cart ---------> POST /cart.add (expectedRevision) ----->  Store API
 check out  ----------> POST /checkout.start       ------------>  Store API
            <---------- redirectUrl or clientSecret
 pays with the provider, returns
            ----------> POST /checkout.confirm     ------------>  order placed

You are building a custom storefront on the Kentro Store API. The user's own web application renders the pages, and its server calls the Store API for the buyer in front of it. Kentro keeps the catalog, prices, stock, buyer accounts, carts, quotes, checkout, orders and invoices. Use the framework the user names; default to Next.js with the App Router.

Read first. Fetch https://docs.kentro.io/llms.txt and these pages, and look up every operation and schema in them before you use it:
- https://docs.kentro.io/docs/ai-agent-instructions.md (rules you must follow)
- https://docs.kentro.io/reference/store-api-getting-started.md
- https://docs.kentro.io/reference/store-api-authentication.md
- https://docs.kentro.io/reference/store-api-conventions.md
- https://docs.kentro.io/reference/store-api-flows.md
- https://docs.kentro.io/docs/guide-custom-storefront.md

Ask the user for these before writing code:
1. The framework and where the application will run.
2. The host of a published storefront in the sandbox (Kentro OS at https://kentro.cc, `Storefronts`). It is the X-Storefront-Host value.
3. A sandbox API key whose permission group holds `storefront:serve`, stored server-side as KENTRO_API_KEY. Never in the chat, never in client code.
4. Which pages to build first: catalog, product, cart, checkout, account or orders.

Rules:
- Call the Store API only from the server: Server Components, Route Handlers or Server Actions in Next.js, server routes in other frameworks. No Client Component, browser script or NEXT_PUBLIC_ variable ever holds the key or a token. The API sends no CORS headers for browsers.
- Base URL https://apis.kentro.dev/store/v1 while building (production https://apis.kentro.live/store/v1); buyer sign-in at https://apis.kentro.dev/auth. Every operation is POST `/<family>.<operation>` with a JSON body, `{}` when it takes no fields.
- Every call sends X-API-Key and X-Storefront-Host (from configuration, lower case, no scheme). Buyer calls add X-Storefront-Buyer and guest calls add X-Storefront-Guest. Also send X-Storefront-Client-Ip and X-Expected-Buyer. The API does not read Authorization.
- Keep buyer and guest tokens on the server, keyed by an httpOnly session cookie. Refresh on 401 with POST /auth/refresh.
- Money is integers in minor units; format it with the store's currency.
- Every cart mutation sends expectedRevision and ownershipVersion from the last cart answer. On 409 CONFLICT, read cart.get again and re-render.
- checkout.start sends idempotencyKey, quoteFingerprint and expectedRevision. Never start a second checkout while one is pending.
- Never cache Store API answers across requests. Call only the operations the Store API reference documents. There is no Kentro SDK: write a small server-only client module.

Steps:
1. A server-only Kentro client: one function that posts to an operation with the headers above and turns refusals (`{ code, message, fieldErrors }`) into typed errors.
2. store.get on each request; render according to access, publicPrices, guestCheckout, fulfillment and currency.
3. Catalog and product pages with the catalog operations on the flows page.
4. Buyers: sign in with POST https://apis.kentro.dev/auth/login/customer `{ email, password, host }`, sign out with POST /auth/logout, sign up with session.signup, and call account.confirm when session.get answers confirmed: false. Guests: session.guest when store.get answers guestCheckout: true.
5. Cart: cart.get, cart.add, cart.set, cart.remove, and cart.update for buyers or cart.contact for guests, plus the cart choice after sign-in when both carts hold items.
6. Quote and checkout: cart.get `{ "quote": true }`, then checkout.start. When state is pending_payment or needs_action, send the buyer to redirectUrl and call checkout.confirm when they return; otherwise poll checkout.status.
7. Orders: orders.list and orders.get.
8. On every refusal, show the buyer the message from the answer; it is written for buyers.

Acceptance checks. Run each one against the sandbox and show the user the requests and responses, with secrets redacted:
- store.get answers 200 for the host; a request without X-Storefront-Host answers 400 VALIDATION.
- A cart.add with a stale expectedRevision answers 409 CONFLICT, and the application re-reads the cart instead of failing.
- cart.get `{ "quote": true }` answers quoteReady: true with a quoteFingerprint for a cart with an address and a payment method.
- checkout.start reaches pending_payment or complete; sending it again with the same idempotencyKey does not create a second order, and checkout.status `{ idempotencyKey, quoteFingerprint }` finds the attempt.
- The signed-in buyer sees the new order in orders.list.
- The production build's client assets contain neither the API key's secret nor the string X-API-Key.