---
name: build-fashioni-fashion-genesis
description: "Adapt and validate the Fashioni fashion Genesis reference for one approved Selldone shop. Use when building audience-led discovery, colour-size variants, editorial shopping, filters, or responsive fashion commerce from the official customer starter."
---

# Build Fashioni Fashion Genesis

Build a truthful, audience-led fashion storefront for one connected Selldone shop. The reference demonstrates visual hierarchy and shopping patterns; the connected shop remains the source of truth.

## Sources and boundaries

- Use `https://github.com/alireza-selldone/official-fashioni` as the public reference starter at snapshot `dc9badb96c7b84e18db84da49a02623b3aec187a`.
- Use `https://fashioni.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, customer audiences, 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: audience taxonomy, product types, colour-size variants, media, inventory, size guidance, prices, discounts, 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 fashion experience

- Lead discovery with the audited audience taxonomy, collections, and product types. Keep editorial content helpful but subordinate to real customer navigation.
- Preserve real colour-size combinations, image relationships, availability, prices, and fit information. Do not invent swatches, size charts, reviews, sales, stock, or promotional claims.
- Add filters, sort controls, collections, style notes, related products, and account or 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 audiences, colour-size variants, price, stock, and fit information against the audited shop.
3. Test navigation, 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.