---
name: build-roben-stays-genesis
description: "Adapt and validate the Roben host-led stays Genesis reference for one approved Selldone shop. Use when building location and date discovery, stay detail, availability-aware booking handoff, or responsive accommodation commerce from the official customer starter."
---

# Build Roben Stays Genesis

Build a truthful, host-led stay-discovery storefront for one connected Selldone shop. The reference demonstrates visual hierarchy and booking patterns; the connected shop remains the source of truth.

## Sources and boundaries

- Use `https://github.com/alireza-selldone/official-roben` as the public reference starter at snapshot `7e4e3319ee2a43e2364b6a8fb93a1943291e579e`.
- Use `https://roben.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, property 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, booking model, brand assets, locales, currencies, required guest and host 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 listing data before mutating it: property identity, location, media, stay type, guests, amenities, availability, price, policies, house rules, and booking handoff.
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 stay-discovery experience

- Use location, dates, guests, and stay type only when those controls have verified effects. Keep listing media, amenities, availability, price, policies, and house rules factual and clearly visible.
- Do not invent availability, dates, rates, booking confirmations, host permissions, reviews, maps, location coordinates, payment, or cancellation terms. Omit a dependent feature or label it as a demo until its contract is verified.
- Build search, filters, map views, stay detail, inquiry, reservation, checkout, guest account, and host surfaces only where current shop data, authorization, and documented runtime 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 and booking 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 listing facts, availability, pricing, policies, and booking handoff against the audited shop.
3. Test search, listing detail, booking handoff, 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.