Cloning a site

> First, check you need this page. It is about reproducing a site that lives > somewhere else — a prospect's existing site, a design you've been handed. If the > site is already hosted on Moseik, stop: Moseik can copy it exactly. Ask your human > to request a copy rather than rebuilding it.

Reproducing an off-platform site at high fidelity is a pixels-first protocol: measure the real thing, build one section at a time, compare screenshots at every step. Follow it in order.

The rules

1. Screenshot the source first. Full-page, at a known viewport width. This is your reference image for the whole job — you compare against it, not against your memory of it.

1. Measure, don't guess. Read the source's _computed_ styles — exact hex colours, font families and weights, font sizes in px, spacing, radii, container widths. Set the theme tokens (PUT /v1/theme) from those, not from an eyeballed approximation. A "close enough" hex is the single biggest fidelity leak.

1. Extract and import the real assets. Pull the actual images and logos from the source and import them first-party (POST /v1/media/import), then reference them as /media/<id>. Never substitute stock imagery. (Off-site src values are rejected anyway.)

1. Build one section at a time, comparing as you go. Author a section, then GET /v1/pages/:id/screenshot and place it beside the source. Adjust until that section matches before moving to the next.

1. Keep a gap ledger. When something can't be reproduced exactly — a font you can't obtain, an effect the platform doesn't support — write it down as an explicit gap with what you did instead. A silent approximation looks like fidelity until a human notices it isn't.

1. "Done" means a side-by-side that a human judges, not "I think it's close."

How the platform helps

• Theme carries the measured palette and type across the whole site, so a colour correction is one token change.
• Site stylesheet holds the shared look (cards, buttons, section rhythm).
• Screenshots (GET /v1/pages/:id/screenshot) give you the loop with no local browser — screenshot a draft version with ?version=… before you publish.
• Components give you working forms and behaviour with plain class hooks you style to match the source, so behaviour never forces a visual compromise.

A section loop, concretely

# 1. reference
(capture the source section screenshot; measure its computed styles)

# 2. set the measured design once
PUT /v1/theme    { …tokens from the measured palette + fonts + scale }
PUT /v1/stylesheet { "css": "…shared section/card/button styles…" }

# 3. author the section, then look
PUT /v1/pages/:id/payload   { "html": "…this section…", "css": "…page-scoped tweaks…" }
GET /v1/pages/:id/screenshot?version=ver_…&w=1440    → compare to the source

# 4. iterate step 3 until the section matches, then move to the next section

If a write is rejected, the reason code names the fix. If a contrast check holds a theme change, the source may ship that contrast knowingly — record it in the gap ledger and decide with a human.