---
name: build-petino-pet-supplies-genesis
description: "Adapt and validate the Petino pet-supplies Genesis reference for one approved Selldone shop. Use when building pet-specific discovery, product suitability detail, variants, repeat-purchase patterns, or responsive pet commerce from the official customer starter."
---

# Build Petino Pet Supplies Genesis

Build a truthful, suitability-led pet-supplies 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-petino` as the public reference starter at snapshot `a98e74c9e10d36aaa750a129c019dc2d423eb38a`.
- Use `https://petino.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, supported pet types, 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: species, breed or size, life stage, diet, material, pack size, ingredients, safety notes, 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 pet-supplies experience

- Let customers discover products from pet context and clear suitability information. Keep pack size, selected variant, ingredients or material, safety guidance, price, stock, and media together on product pages.
- Preserve real product constraints and inventory. Do not invent veterinary claims, suitability, ingredients, nutrition, stock, subscription, reviews, promotions, or pricing.
- Add repeat-purchase, filtering, recommendations, editorial guidance, 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 suitability, variants, ingredient or material facts, price, stock, and safety 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.