---
name: build-digini-electronics-genesis
description: "Adapt and validate the Digini consumer-electronics Genesis reference for one approved Selldone shop. Use when building product-family discovery, technical product detail, variants, filters, or responsive electronics commerce from the official customer starter."
---

# Build Digini Electronics Genesis

Build a truthful, product-led electronics storefront for one connected Selldone shop. The reference demonstrates a visual and information-hierarchy pattern; the connected shop remains the source of truth.

## Sources and boundaries

- Use `https://github.com/alireza-selldone/official-digini` as the public reference starter at snapshot `587a19c7a5ec2aba0e58acc2fd8c9070e7fd47e9`.
- Use `https://digini.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, business model, 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 existing catalogue before mutating it: product families, model names, variants, images, technical specifications, included items, warranty, 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 electronics experience

- Start with product-family navigation and clear technical storytelling. Keep model, price, availability, selected variant, media, and key specifications together on product pages.
- Preserve real variants and their media/inventory relationships. Do not collapse model numbers, storage, memory, dimensions, included items, warranty, or technical facts into invented generic copy.
- Make filters, sorting, comparison, buying guidance, related products, reviews, and promotional surfaces only when the current shop data and public storefront contract 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, stock 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 product, variant, price, stock, and technical-detail states against the audited shop.
3. Test search/browse, product detail, add-to-cart or checkout only where those 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.