---
name: build-watchino-luxury-watches-genesis
description: "Adapt and validate the Watchino luxury-watch Genesis reference for one approved Selldone shop. Use when building collection discovery, watch-model detail, technical specifications, variants, or responsive luxury commerce from the official customer starter."
---

# Build Watchino Luxury Watches Genesis

Build a truthful, restrained luxury-watch storefront for one connected Selldone shop. The reference demonstrates visual hierarchy and product-detail patterns; the connected shop remains the source of truth.

## Sources and boundaries

- Use `https://github.com/alireza-selldone/official-watchino` as the public reference starter at snapshot `aad995e835a64596442993a6b3fe893ebbd3fe57`.
- Use `https://watchino.selldone.shop/` as the public experience reference.
- Treat the reference as inspiration for layout and interaction only. Do not reuse its name, logo, domains, shop handles, identifiers, copy, product data, photography, or any protected identity in a customer build.
- Prefer the current connected Selldone MCP resources and storefront guidance whenever they conflict with this reference.

## Establish scope before editing

1. Confirm the intended shop, collections, brand assets, locales, currencies, required customer flows, destination GitHub repository, Cloudflare account, and production domain.
2. Verify the Selldone MCP connection with a read-only call. Never request an MCP token, GitHub token, Cloudflare token, API key, refresh token, client secret, or manual shop ID in chat.
3. Audit the catalogue before mutating it: collection, model name, case, movement, material, dial, strap, water resistance, warranty, variants, prices, stock, and currency.
4. Build a capability matrix: **live** for verified contracts, **derived** for documented calculations, **demo** only when visibly marked, and **blocked/omitted** when a contract is missing.
5. Get explicit approval before each external mutation group: creating or pushing a repository, creating or connecting a Cloudflare project, production deployment, DNS/custom-domain changes, or Selldone administrative changes.

## Build the luxury-watch experience

- Keep the visual hierarchy restrained and model-led. Make selected product media, model identity, material, movement, dial, strap, water resistance, warranty, price, stock, and variants easy to find.
- Preserve real product facts and availability. Do not invent provenance, rarity, materials, specifications, warranty, stock, reviews, price history, promotions, or authentication claims.
- Add collection pages, filters, comparison, related watches, editorial content, account, and checkout surfaces only where current shop data and documented public contracts support them.
- Use accessible semantic controls, keyboard focus, useful alt text, honest loading/empty/error states, reduced motion, and mobile-first layouts at 375, 768, 1024, and 1440px.
- Derive every visible price, inventory state, and purchase action from documented runtime contracts. Never place MCP credentials or privileged backoffice credentials in browser code.

## Repository and deployment safety

Before cloning, pulling, or pushing, inspect `git status --short --branch`, `git remote -v`, the current branch, and the destination remote. Preserve the public starter as `upstream`; use the approved customer repository as `origin`.

Do not run a blind pull, force-push, overwrite a non-empty destination, or publish without a fresh approval. For upstream updates, fetch into a dedicated sync branch, review the merge, rebuild, and keep customer configuration separate from reference changes.

Use the repository lockfile and documented build scripts. Deploy only the static production output through an approved Cloudflare Workers Build. Do not commit build output or expose secrets. Connect a custom domain, change DNS, or publish production only after the user approves the exact account, project, branch, and domain.

## Verify before handoff

1. Run the documented build and automated checks, then `git diff --check`.
2. Review collection, model, technical specifications, variants, price, and stock against the audited shop.
3. Test collection browsing, filtering, product detail, and checkout only where contracts are verified, plus empty/error states at phone, tablet, laptop, and desktop widths.
4. Report the changed files, remaining blocked capabilities, and every external action that still needs approval.